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

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

------- Comment #8 from rogerio at rilhas dot com  2010-08-11 00:54 -------
I think you are wrong, I'm not depending on undefined behaviour. When I request
&format that is clearly defined: I should be getting the address of the format
pointer as placed on the stack. Just like I would when requesting the address
of an int parameter placed on the stack, I would get its stack address. If were
to write to that address I would write onto the stack. That is well defined.
Then, by another well defined attribute (the calling convention) I should be
able to navigate the stack to get the other parameters. There is no hack here!
It is all well defined. As long as the compiler doesn't "mess it up" and do
something "undocummented" or something that violates these well-defined
behaviours then everything is just fine. A compiler that doesn't verify both of
these 2 well-defined characteristics simultaneously has a bug.

I'm not coding for the Xbox nor for NT 3.5, but I assume that if I can get
Microsoft's compiler to use the calling convention that I want I will be able
to get the code to run. The reasoning is very simple: when I request
Microsoft's compilers something like &format I get the stack address for the
format variable placed on the stack (as expected, not some copy unpredictably
placed somewhere else on the stack), and as Microsoft's compilers strictly
respect the calling conventions then I'm sure it would work. Microsoft's
compilers don't "mess it up" while optimizing. The only possibility for it not
to work would be for Microsoft's compiler not to let me select the calling
convention I wanted, which I seriously doubt.

To prove this I just compiled the code to Windows Mobile and it works just fine
on an ARM platform (my mobile phone), compiled with Visual Studio 2008, despite
the fact that it is a very diferent platform from x86. In fact, it is
conceptually very close to PowerPC, so I think this code would compile
correctly on PowerPC as well.

As I stated there is no undefined behaviour here, and I know exactly what I am
doing when I'm navigating the stack based on the address of the original format
string on the stack and on the calling convention used. That is what I would do
if programming in assembly language, so the compiler must not "mess up" these 2
well defined items.

So there is nothing wrong with my source, and it works everywhere I tried
except with GCC. From your comment I suspect I'm just wasting my time, because
you seem to be missing the point altogether. But of course I respect your
position of not fixing this (as I must, since I'm not the one working on
GCC!!).

I reopened the bug just to give you this last piece of information about the
Windows Mobile (no need to reply if you don't want to). Since you are very keen
on closing this report whithout backing your claims and clearly explaining how
come you say the behaviour is not defined I don't feel the interest to persue
this issue any further (especially because I feel it shouldn't be necessary for
me to explain all this, I think it should be fairly obvious to people
developing a compiler), so I will just drop LINUX for now (until I have the
oportunity to test other compilers).

Thanks for your attention anyway!


-- 

rogerio at rilhas dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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