From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3268 invoked by alias); 11 Aug 2010 14:10:44 -0000 Received: (qmail 3136 invoked by uid 48); 11 Aug 2010 14:10:21 -0000 Date: Wed, 11 Aug 2010 14:10:00 -0000 Message-ID: <20100811141021.3134.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: "redi at gcc dot gnu dot org" 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/msg00852.txt.bz2 ------- Comment #19 from redi at gcc dot gnu dot org 2010-08-11 14:10 ------- (In reply to comment #18) > 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 It's Linux (or GNU/Linux) not LINUX. > "format_indirect" as GCC does not allow me to use vsnprintf on a function that > doesn't take variable parameters. I explained why, see 7.15 in the C99 standard. > 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. Not if you use it correctly, which you are not doing. void format_direct3(char* dst_buffer, int dst_buffer_size_bytes, const char* format, ...) { va_list va; va_start(va, format); vsnprintf(dst_buffer, dst_buffer_size_bytes, format, va); va_end(va); } > As you can see I've tried very hard to explain all details of the problem, and > why this is a bug in GCC. GCC claims to support C and C++. Can you point to part of either standard which says your code is valid? > You just keep dismissing all my arguments without any justification whatsoever. What you're doing is not defined by the C or C++ standard. GCC is a C and C++ compiler. Can you show where in the C or C++ standards it says the stack must be laid out as you want? > 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, Because the C and C++ standards do not make any guarantees about layout of arguments in memory, so when using a C or C++ compiler to compile C or C++ code you should not assume any particular layout. > 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. The standard does not define how arguments are laid out, therefore it is undefined. > So I'm stuck with your "you can't because you can't" replies and this > conversation will not progress any further, of course. The onus is on you to show where in the C standard it says that your code is well defined. If the standard doesn't say it, it's not portable and not well defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249