[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault

["rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- 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