Path: utzoo!news-server.csri.toronto.edu!rutgers!ucsd!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.lang.c Subject: Re: A quick question... Message-ID: <10953@dog.ee.lbl.gov> Date: 14 Mar 91 23:40:34 GMT References: <1991Mar12.030759.26698@nntp-server.caltech.edu> <1991Mar12.062941.2369@nntp-server.caltech.edu> <24247@hydra.gatech.EDU> <1991Mar13.174154.12537@nntp-server.caltech.edu> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 155 X-Local-Date: Thu, 14 Mar 91 15:40:34 PST In article <1991Mar13.174154.12537@nntp-server.caltech.edu> eychaner@suncub.bbso.caltech.edu writes: >> *((short *)arrayptr)++ = othervalue(); >... is what I meant. But this does not mean anything. A cast is defined semantically as `assign the cast-expression value to an unnamed temporary variable whose type is given by the cast'. Thus, aside from the fact that a cast produces a value, not an object, and therefore cannot be incremented, this expression is otherwise semantically identical to: { short *temp; temp = arrayptr; *temp++ = othervalue(); } In other words, if the increment were legal, it would not alter arrayptr at all, but rather some mysterious temporary variable. Fortunately, the increment is illegal. As someone else pointed out earlier (but it bears repeating [either that or you might as well give up on comp.lang.c :-) ]), the expression void f(char *arrayptr) { *(*(short **)&arrayptr)++ = 1; *(*(short **)&arrayptr)++ = 2; *(*(short **)&arrayptr)++ = 3; } *is* legal, but is probably not what you meant anyway. Disassembling one of the above expressions into its components reveals why: arrayptr: &arrayptr: (short **)&arrayptr: short **temp; temp = (address of arrayptr, treated as if it were a pointer to pointer to short); *(short **)&arrayptr: [note 1] (*(short **)&arrayptr)++: [note 1] and also add 1 to *temp before next sequence point *(*(short **)&arrayptr)++ [note 1] and also add 1 to *temp before next sequence point To figure out what this mess meant, I shortened the last three <>-bracketed triples to just use `*temp' and `**temp', without first writing down what `*temp' is, so now we need to do that: [note 1] *temp is: The object found at the address given by `temp'. Temp is a treated as if it were a pointer to pointer to short)>. But what *is* this value? The answer is: `We have no idea and we cannot find out without going to the compiler, or the compiler's documentation or author or whatever, and finding out what it does on this particular machine.' We do not know, and cannot find out (without going into the guts of the compiler), what you get when you treat an as if it were something else. Just for fun, though, we can go ahead and dig into the guts of a compiler. I will take a typical C compiler for a Data General MV series machine. The Data General MV series has two kinds of pointers, `byte pointers' and `word pointers'. Both are 32 bits long, but one looks vaguely like this: WWW...WWWI [note: I am deliberately leaving out the ring stuff] (mostly because I cannot remember how it worked) and the other like this: BWWW...WWW where W is a word address, `I' is an indirection bit (normally 0), and B is the index number of a byte within a two-byte word. So if we have `arrayptr' as an object in memory, it is a byte pointer and looks like the second: BWWW...WWW [arrayptr] If we take its address, we get a word pointer that points to the above byte pointer: WWW...WWWI [&arrayptr] ----> BWWW...WWW [arrayptr] Now we will treat the word pointer on the left as if it were a `pointer to pointer to short'. This means we will pretend that what it points to (on the right) is a `pointer to short'---specifically, that it is a word pointer: actual: WWW...WWWI [&arrayptr] ----> BWWW...WWW [arrayptr] pretend:WWW...WWWI [&arrayptr] ----> WWW...WWWI [arrayptr] Next, we will fetch the thing our `pretend' pointer points to, i.e., 32 bits of `WWW...WWWI'. The actual bits found at that location are `BWWW...WWW'. We will look at the top 31 bits of those 32 bits and fetch a word from that location, i.e., the location (W/2 + B<<31). If arrayptr points to `byte 0 of word at 0x3004', this will be `word at 0x1802', while if arrayptr points to `byte 1 of word at 0x6480', this will be `word at 0x40003240'. Once we find that word (if it is in our address space at all), we will look at the bottom bit, the `I' bit, and if it is set we will fetch the word to which this word points. So if `arrayptr' happens to point to byte 0 of word 0x51379', we will first look in location 0x289c, see where that points (taken as if it were a word pointer), and go warping off to wherever that is. In other words, by closing our eyes and pretending that this byte pointer is a word pointer, we are going to - cut the word address in the byte pointer in half; - if the byte pointer pointed to the odd-numbered byte, add 2^31; - if the byte pointer was odd, head off into the ozone. We are definitely NOT going to get two bytes from the place to which `arrayptr' points. Just for more fun, we can follow what happens when we use instead a proper expression: ((short *)(arrayptr += sizeof(short)))[-1] On the D/G, this means: - add one to `arrayptr', leaving the top bit alone (i.e., point to the next word); - treat the result as if it were a pointer to words, i.e., shift it left one bit and put a zero in the bottom (I) bit; - subtract two from the resulting pointer (i.e., point to the previous word); - fetch the word from the resulting location. The trick is that arithmetic on a pointer depends on what *kind* of pointer it is. If it is a byte pointer, we add 1 to move forward one word, and add 0x80000000 and then add the carry to move forward one byte. If it is a word pointer, we add 2 to move forward one word, and there is no way at all to move forward one byte. Conversion between byte and word pointers is not just `bits as is'; it requires shift instructions. The compiler does this whenever you have `word pointer' and `byte pointer' next to each other, but if you cheat (by casting &foo to some other type) you are telling the compiler to throw away that information, and skip the conversion. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov