This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
- From: "redi at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 11 Aug 2010 14:10:21 -0000
- Subject: [Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
- References: <bug-45249-19547@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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