Re: Compiler Recommendations

["Jerry Feldman-2" <user=4@nabble.blu.org>]

 On Thu, 3 Jan 2008 16:00:11 -0800 
"Kristian Erik Hermansen" <[hidden email]> wrote: 

> On 03 Jan 2008 17:19:34 -0500, Kevin D. Clark <[hidden email]> wrote: 
> > Q:  If I write the code int i, j; can I assume that (&amp;i + 1) == &amp;j? 
> > A:  Only sometimes. It's not portable, because in EBCDIC, i and j 
> >     are not adjacent. 
> >                 -- Infrequently Asked Questions in comp.lang.c 
> 
> The answer to this is also "no" because some compiler 
> randomize/reorder both compile and runtime variable allocations for 
> security reasons :-) 

First, this has nothing to do with EBCDIC. EBCDIC only would apply to 
character data, not integer data. EBCDIC code is an IBM 8-bit encoding 
analogous to ASCII.  But, the answer, is you cannot assume. Compilers 
and Linkers will move data around for many reasons. Normally 2 like 
data elements would probably be allocated adjacent, but also compilers 
like to use registers, so i and j may not even be allocated. 

War story: 
I once worked on a system that had something like: 
struct foo { 
... 
} bar; 
int barcheck; 

For some reason the idiot who wrote the code had never heard of 
sizeof.  There were several cases of: 
unsigned int  size = &amp;barcheck - &amp;bar; 
struct foo *cfoo = (struct cfoo *)malloc(size); 

Before I came there had been a couple of projects to move the code to a 
newer compiler (because of a new ICE). In the case of the new compiler, 
bar was allocated in a separate area from barcheck; In any case, what 
would happen would be that the code would crash when loading because 
size was a very large number and malloc returned NULL. There were 
several cases of that kind of code.   

-- 
-- 
Jerry Feldman <[hidden email]> 
Boston Linux and Unix 
PGP key id: 537C5846 
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846 
_______________________________________________ 
Discuss mailing list 
[hidden email] 
http://lists.blu.org/mailman/listinfo/discuss