Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 (&i + 1) == &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 = &barcheck - &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
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |