From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds To: Tim Hollebeek Cc: craig@jcb-sc.com, davem@redhat.com, mark@codesourcery.com, chip@perlsupport.com, egcs@egcs.cygnus.com Subject: Re: Linux and aliasing? Date: Fri, 04 Jun 1999 08:55:00 -0000 Message-id: References: <199906041539.LAA27085@wagner.Princeton.EDU> X-SW-Source: 1999-06/msg00146.html On Fri, 4 Jun 1999, Tim Hollebeek wrote: > > If you do the same type tricks but use intermediate variables to > improve readability, you lose. In fact, simply taking an expression > and decomposing it into constituent parts can change the behavior of > code under this rule. Absolutely horrible. Uhh. You're right. I considered it, but I didn't find it "absolutely horrible", I thought it could be considered a feature in that it was only ever entirely local to =one= memory operation. That's not something new per se: the gcc __extension__ thing is kind of similarly meant to silence things up locally to that expression. But I can see why you wouldn't like it, and I understand your argument. I don't how how else you would limit the scope of anything like this, though (scoping it to something larger than a single dereference sounds like a horrible rats nest to me, but opnions can certainly differ). > Unless you're suggesting data flow analysis to figure out which > pointers values could have been derived from a casted pointer??? ick, > ick, ick. Oh, no, no, no. Shudder. I hope nobody took it that way. Barf. I meant the features as something to expressly allow a local override. Think of the rule more as an issue of "poisoning" the dereference operator rather than poisoning the _pointer_. In a kind of silly "precedence rule" notation, it would be *(char *)y becomes (*(char *)) y where it is the "*(char *)" thing that makes the alias go away. (Now somebody is going to flame my ass off for mixing C and a non-C precedence rule). And maybe the above is hard to do because by the time you actually would want to do the above logic the information isn't really there any more. That's entirely possible, and if people tell me it's a bad idea for reason X I'll shut up about it, but I'd try to come up with another one. Deal? Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds To: Tim Hollebeek Cc: craig@jcb-sc.com, davem@redhat.com, mark@codesourcery.com, chip@perlsupport.com, egcs@egcs.cygnus.com Subject: Re: Linux and aliasing? Date: Wed, 30 Jun 1999 15:43:00 -0000 Message-ID: References: <199906041539.LAA27085@wagner.Princeton.EDU> X-SW-Source: 1999-06n/msg00146.html Message-ID: <19990630154300.qYkrJ46ZTlYwh2d77XEJRgLM1IWXwVGgWXZgb53m54U@z> On Fri, 4 Jun 1999, Tim Hollebeek wrote: > > If you do the same type tricks but use intermediate variables to > improve readability, you lose. In fact, simply taking an expression > and decomposing it into constituent parts can change the behavior of > code under this rule. Absolutely horrible. Uhh. You're right. I considered it, but I didn't find it "absolutely horrible", I thought it could be considered a feature in that it was only ever entirely local to =one= memory operation. That's not something new per se: the gcc __extension__ thing is kind of similarly meant to silence things up locally to that expression. But I can see why you wouldn't like it, and I understand your argument. I don't how how else you would limit the scope of anything like this, though (scoping it to something larger than a single dereference sounds like a horrible rats nest to me, but opnions can certainly differ). > Unless you're suggesting data flow analysis to figure out which > pointers values could have been derived from a casted pointer??? ick, > ick, ick. Oh, no, no, no. Shudder. I hope nobody took it that way. Barf. I meant the features as something to expressly allow a local override. Think of the rule more as an issue of "poisoning" the dereference operator rather than poisoning the _pointer_. In a kind of silly "precedence rule" notation, it would be *(char *)y becomes (*(char *)) y where it is the "*(char *)" thing that makes the alias go away. (Now somebody is going to flame my ass off for mixing C and a non-C precedence rule). And maybe the above is hard to do because by the time you actually would want to do the above logic the information isn't really there any more. That's entirely possible, and if people tell me it's a bad idea for reason X I'll shut up about it, but I'd try to come up with another one. Deal? Linus