From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20826 invoked by alias); 11 Aug 2010 13:12:04 -0000 Received: (qmail 18782 invoked by uid 48); 11 Aug 2010 13:11:40 -0000 Date: Wed, 11 Aug 2010 13:12:00 -0000 Message-ID: <20100811131140.18781.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/msg00848.txt.bz2 ------- Comment #18 from rogerio at rilhas dot com 2010-08-11 13:11 ------- Of course vsnprintf was my first choice, as you can see from the WIN32 part of the code I sent you. In WIN32 I can use vsnprint in a very natural and predictable way in "format_indirect". In LINUX this cannot be used in "format_indirect" as GCC does not allow me to use vsnprintf on a function that doesn't take variable parameters. I tried to bypass it specifying variable parameters for "format_indirect", but of course the results are wrong because GCC will have placed the wrong address in "format_address" inside "format_indirect". So, in fact, vsnprintf will have exactly the same problem as I had, and I would report exactly the same bug like I did. As you can see I've tried very hard to explain all details of the problem, and why this is a bug in GCC. You just keep dismissing all my arguments without any justification whatsoever. When you did justify I just proved your arguments to be false (no disrespect intended) in the hope that this conversation would progress. You don't explain why I can't rely on the calling convention to ensure the parameters will be adjacent, and you don't explain why I can't use &format to get the address of that packed data on the stack. You just keep invoking some standard where these 2 things are alledgedly not defined but without materializing it (which I don't believe you can anyway!). You have not yet shown why GCC is not required to place the parameters correctly on the stack, and why GCC does not need to give me the true &format. So I'm stuck with your "you can't because you can't" replies and this conversation will not progress any further, of course. Best regards, Rogerio -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249