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

["rogerio at rilhas dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #42 from rogerio at rilhas dot com  2010-08-11 22:51 -------
> It doesn't make it an array in the C sense.

What is an array in the C sense? Isn't it a sequence of entries? Is there any
other concept to go along with it that allows PTR4 to be set to any other value
than X? If so, where did you read it? I read in C99 that a pointer is simply a
variable that contains an address, and that C doesn't navigate "arrays in the C
sense" in anyway diferently than with "simple pointers". Do you have a C99
section that shows a distinction significant to this issue?

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

Can you explain then how &X gets the format parameter from the stack and X[1]
doesn't get the next adjacent entry on the stack? Note that C99 is pretty clear
about the fact that X[1] will access bytes 4 to 7 after X. Can you backup your
claim with C99 or any other reference besides your personal interpretation?

> &X does _not_ get you access to anything like a "stack" as there is
> no such concept in the C language.

No problem. I don«t want PTR4 to be a specific "pointer to stack", I want it to
be a "general pointer to memory". I don«t need more than that and C99 says I
should be able to get such "generic address" to PTR4 and dereference it. Where
can it be read that to access stack address space I should need a special
pointer? Where does it read I cannot derreference PTR4 if it points to stack?
Where can it be read that if I dereference PTR4 while its is pointing to stack
that pointer arithmetic will not be the same as any other?

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

No, cdecl states that &x+1==&y, and that &x+2==&z. If a compiler is
cdecl-compliant I can trust this to be true.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249