------- Comment #36 from rguenth at gcc dot gnu dot org 2010-08-11 22:27 ------- (In reply to comment #35) > (In reply to comment #33) > > Yes GCC implements that ABI and &argument will get you the address of that > > argument. > > If that is so then the format parameter will be placed at some address X, > param > 1 at address X+4, param 2 at address X+8, and param 3 at X+12. Figure 3-48 > shows these addresses to be very predictable and well defined. It is very > important for you to follow this reasoning, as this makes all the difference. > This is what makes X an array of 4 entries, and not simply an array of 1 > isolated entry.
It doesn't make it an array in the C sense. > > But that does not deter from that &argument will produce an array of > > size 1 rather than what you want which is the rest of the arguments too. > > Can you backup your claim that "&argument will produce an array of size 1"? > Can > you even backup the claim that &argument "produces" any array at all? As I > showed using C99, the & just produces a value X (an address which can be > travelled without boundary issues), so C99 shows that "&argument" does not > "produce" an array, nor allocates storage for a 1-entry copy of "argument" at > some unpredictable address Y (C99 clearly states that &a retuns "address of > a", > not "address of copy of a"). So I don't see how you could ever backup your > claim with any standard, but I'm open to be surprised by your creativity! :-) > > Based on C99 const char** PTR4=&format will set PTR4 to X. It's all good as > long as PTR4 contains the value X. As C99 defines this, GCC doesn't have the > option to copy the "format" to some random address Y and return it when I ask > for "&format". It simply should not do this. I've backed this claim with C99 > text that states that & operator is the address of the item, not the address > of > a copy of the item invented by the compiler. > > I also showed you in C99 that PTR4[0] accesses the 4 bytes of address X, and > I've backed up my claim (based on C99) that PTR4[1] will access the 4 bytes at > X+4 (i.e the 4 bytes of param 1), and that there is no "size of array > limitation" specified in C99. Similarly, PTR4[2] will access the 4 bytes at > X+8, (i.e the 4 bytes of param 2), and so on. I've clearly backed up this with > C99. > > So, all this is backed up. Can you refute the reasoning up to this point with > any C99 reference? Or a reference to any other standard for that matter? &X gives you an address of X which happens to be on the stack. Following parameters happen to be in adjacent stack slots. Still C does not give you a way to access adjacent parameters by doing pointer arithmetic on &X. &X does _not_ get you access to anything like a "stack" as there is no such concept in the C language. In foo (int x, int y, int z) there are only x, y and z. There is no array of parameters, the only "arrays" are that of implicit size 1 at locations &x, &y and &z which allows you to compute &x + 1 (but not dereference that pointer). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
