This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]