From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27717 invoked by alias); 11 Aug 2010 00:55:01 -0000 Received: (qmail 27613 invoked by uid 48); 11 Aug 2010 00:54:31 -0000 Date: Wed, 11 Aug 2010 00:55:00 -0000 Message-ID: <20100811005431.27612.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rogerio at rilhas dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-08/txt/msg00792.txt.bz2 ------- 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