--- Comment #56 from jakub at gcc dot gnu dot org 2010-08-12 08:20 ---
Please stop wasting your and GCC developers time. As several people have
explained, your code triggers undefined behavior in C/C++, so it can do
anything at runtime. The fact that it happens to work as you expect
--- Comment #57 from rogerio at rilhas dot com 2010-08-12 10:16 ---
(In reply to comment #56)
Please stop wasting your and GCC developers time. As several people have
explained, your code triggers undefined behavior in C/C++, so it can do
anything at runtime. The fact that it
--- Comment #58 from paolo dot carlini at oracle dot com 2010-08-12 10:18
---
.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #12 from rogerio at rilhas dot com 2010-08-11 11:20 ---
Created an attachment (id=21452)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21452action=view)
Preprocessed file (with example 2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #13 from rogerio at rilhas dot com 2010-08-11 11:21 ---
Created an attachment (id=21453)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21453action=view)
Source file (example 2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #14 from rogerio at rilhas dot com 2010-08-11 11:22 ---
No, you are not correct. The equivalent code to what I'm doing would be
something like:
int buffer[4]; // 16 bytes on stack
buffer[0]=(int)format
buffer[1]=(int)10
buffer[2]=(int)another_string
buffer[3]=(int)20
call
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-08-11 11:37
---
(In reply to comment #14)
No, you are not correct. The equivalent code to what I'm doing would be
something like:
int buffer[4]; // 16 bytes on stack
buffer[0]=(int)format
buffer[1]=(int)10
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-08-11 11:41
---
Btw, just use vsnprintf.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #17 from redi at gcc dot gnu dot org 2010-08-11 11:55 ---
As already stated, what you are doing is not valid C or C++, the standards do
not guarantee the behaviour you are expecting w.r.t stack layout, and an
optimising C or C++ compiler follows the rules of the language
--- 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
--- 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
--- Comment #20 from matz at gcc dot gnu dot org 2010-08-11 16:10 ---
A conforming variant of what you probably are trying to code is:
#include stdio.h
#include stdarg.h
void format_indirect(char* dst_buffer, size_t
--- Comment #21 from rogerio at rilhas dot com 2010-08-11 17:04 ---
Subject: Re: Indirect variable parameters sometimes cause
segmentation fault
Yes, I was using that solution up to 2003, but then I stopped
using it in favour of the more confortable format (the one I
showed you)
--- Comment #22 from rogerio at rilhas dot com 2010-08-11 17:15 ---
(In reply to comment #19)
(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
--- Comment #23 from pinskia at gcc dot gnu dot org 2010-08-11 17:49
---
First off I already mentioned what is undefined in this example in comment #11.
The part of the standard that mentions about arrays. And how the address of a
scalar is considered an array of size 1. I don't
--- Comment #24 from redi at gcc dot gnu dot org 2010-08-11 17:57 ---
(In reply to comment #22)
If GCC supports cdecl on a x86 plaform then it must support the packing of
parameters as defined for x86 (it is not standardize that I know of, but it is
well defined). I sugest reading
--- Comment #25 from rogerio at rilhas dot com 2010-08-11 19:51 ---
(In reply to comment #24)
(In reply to comment #22)
If GCC supports cdecl on a x86 plaform then it must support the packing of
parameters as defined for x86 (it is not standardize that I know of, but it
is
--- Comment #26 from pinskia at gcc dot gnu dot org 2010-08-11 19:54
---
This code does not compile in GCC, and so is not portable.
No it is not portable because that code is just plain invalid; though MS
accepts it as it is implementing something called move constructor as an
--- Comment #27 from rogerio at rilhas dot com 2010-08-11 20:04 ---
(In reply to comment #26)
This code does not compile in GCC, and so is not portable.
No it is not portable because that code is just plain invalid; though MS
accepts it as it is implementing something called move
--- Comment #28 from rogerio at rilhas dot com 2010-08-11 20:07 ---
(In reply to comment #23)
First off I already mentioned what is undefined in this example in comment
#11.
The part of the standard that mentions about arrays. And how the address of
a
scalar is considered an
--- Comment #29 from rguenth at gcc dot gnu dot org 2010-08-11 20:33
---
(In reply to comment #28)
(In reply to comment #23)
First off I already mentioned what is undefined in this example in comment
#11.
The part of the standard that mentions about arrays. And how the
--- Comment #30 from rogerio at rilhas dot com 2010-08-11 20:58 ---
Really? Your comment #11 has so many mistakes in it that maybe you are the one
who should learn a little bit more on C.
The ABI is not of concern here really. The issue comes down to you have:
char *a;
char **b = a;
--- Comment #31 from pinskia at gcc dot gnu dot org 2010-08-11 21:02
---
Didn't you understand the equivalent code would be:
No, as the variables act the same if they are automatic variables or arguments.
there is no different between the two. That has been my point from the
--- Comment #32 from rogerio at rilhas dot com 2010-08-11 21:12 ---
(In reply to comment #31)
Didn't you understand the equivalent code would be:
No, as the variables act the same if they are automatic variables or
arguments.
there is no different between the two. That has been
--- Comment #33 from pinskia at gcc dot gnu dot org 2010-08-11 21:16
---
Yes GCC implements that ABI and argument will get you the address of that
argument. But that does not deter from that argument will produce an array of
size 1 rather than what you want which is the rest of the
--- Comment #34 from redi at gcc dot gnu dot org 2010-08-11 21:27 ---
(In reply to comment #25)
In other words my code is not portable because GCC is not doing what it
should.
GCC causes code not to be portable a lot of times, like in the following case
(which does not compile
--- Comment #35 from rogerio at rilhas dot com 2010-08-11 22:16 ---
(In reply to comment #33)
Yes GCC implements that ABI and argument will get you the address of that
argument.
If that is so then the format parameter will be placed at some address X, param
1 at address X+4, param 2
--- Comment #36 from rguenth at gcc dot gnu dot org 2010-08-11 22:27
---
(In reply to comment #35)
(In reply to comment #33)
Yes GCC implements that ABI and argument will get you the address of that
argument.
If that is so then the format parameter will be placed at some
--- Comment #37 from rguenth at gcc dot gnu dot org 2010-08-11 22:30
---
Btw, 6.5.6/7 For the purposes of these operators, a pointer to an object that
is
not an element of an array behaves the same as a pointer to the first element
of an array of length one with the type of the object
--- Comment #38 from rogerio at rilhas dot com 2010-08-11 22:35 ---
(In reply to comment #34)
(In reply to comment #25)
In other words my code is not portable because GCC is not doing what it
should.
GCC causes code not to be portable a lot of times, like in the following
--- Comment #39 from rogerio at rilhas dot com 2010-08-11 22:37 ---
(In reply to comment #37)
Btw, 6.5.6/7 For the purposes of these operators, a pointer to an object that
is
not an element of an array behaves the same as a pointer to the first element
of an array of length one with
--- Comment #40 from rguenth at gcc dot gnu dot org 2010-08-11 22:48
---
(In reply to comment #39)
(In reply to comment #37)
Btw, 6.5.6/7 For the purposes of these operators, a pointer to an object
that
is
not an element of an array behaves the same as a pointer to the first
--- Comment #41 from rogerio at rilhas dot com 2010-08-11 22:50 ---
It doesn't make it an array in the C sense.
What is an array in the C sense? Isn't it a sequence of entries? Is there any
other concept to go along with it that allows PTR4 to be set to any other value
than X? If so,
--- Comment #42 from rogerio at rilhas dot com 2010-08-11 22:51 ---
It doesn't make it an array in the C sense.
What is an array in the C sense? Isn't it a sequence of entries? Is there any
other concept to go along with it that allows PTR4 to be set to any other value
than X? If so,
--- Comment #43 from rogerio at rilhas dot com 2010-08-11 22:52 ---
It doesn't make it an array in the C sense.
What is an array in the C sense? Isn't it a sequence of entries? Is there any
other concept to go along with it that allows PTR4 to be set to any other value
than X? If so,
--- Comment #44 from rogerio at rilhas dot com 2010-08-11 22:53 ---
(In reply to comment #36)
(In reply to comment #35)
(In reply to comment #33)
It doesn't make it an array in the C sense.
What is an array in the C sense? Isn't it a sequence of entries? Is there any
other
--- Comment #45 from rogerio at rilhas dot com 2010-08-11 22:54 ---
(In reply to comment #43)
(please disregard this duplication)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #46 from rogerio at rilhas dot com 2010-08-11 22:54 ---
(In reply to comment #42)
(please disregard this duplication)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #47 from rogerio at rilhas dot com 2010-08-11 22:55 ---
(In reply to comment #41)
(please disregard this duplication)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #48 from pinskia at gcc dot gnu dot org 2010-08-11 22:58
---
No, cdecl states that x+1==y, and that x+2==z.
Maybe the ABI says that but that does not mean you can access x + 1 to get
to y at least in a standard defined way. That is the whole point of it
acting as it was
--- Comment #49 from rogerio at rilhas dot com 2010-08-11 23:22 ---
(In reply to comment #40)
(In reply to comment #39)
(In reply to comment #37)
Why do you think GCC makes it the address of a copy?
Well, the first observation was dumpung the memory around the returned address
to
--- Comment #50 from rogerio at rilhas dot com 2010-08-11 23:43 ---
(In reply to comment #48)
No, cdecl states that x+1==y, and that x+2==z.
Maybe the ABI says that but that does not mean you can access x + 1 to get
to y at least in a standard defined way. That is the whole point of
--- Comment #51 from rogerio at rilhas dot com 2010-08-12 02:08 ---
Given all that we have established in our conversation I think I can now
demonstrate the bug easily.
The entry to the format_direct call (in the main function, just before
entering the format_direct function)
--- Comment #52 from rogerio at rilhas dot com 2010-08-12 02:09 ---
Created an attachment (id=21462)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21462action=view)
Snapshot 1 - Breakpoint before calling format_direct
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #53 from rogerio at rilhas dot com 2010-08-12 02:10 ---
Created an attachment (id=21463)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21463action=view)
Snapshot 2 - Inside format_direct to show cdecl ABI parameter packing
--
--- Comment #54 from rogerio at rilhas dot com 2010-08-12 02:12 ---
Created an attachment (id=21464)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21464action=view)
Snapshot 3 - Breakpoint before calling format_indirect (showing dump for
$ebp+0x10)
--
--- Comment #55 from rogerio at rilhas dot com 2010-08-12 02:12 ---
Created an attachment (id=21465)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21465action=view)
Snapshot 4 - Showing incorrect value for PTR4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #1 from rogerio at rilhas dot com 2010-08-10 22:03 ---
Created an attachment (id=21448)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21448action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #2 from rogerio at rilhas dot com 2010-08-10 22:03 ---
Created an attachment (id=21449)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21449action=view)
Source file with comments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #3 from rogerio at rilhas dot com 2010-08-10 22:04 ---
Created an attachment (id=21450)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21450action=view)
Compilation script (for the working and non-working builds)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-10 22:07 ---
This code will never work as you are not using va_start/va_end to access the
arguments. For format_indirect you should just pass around a va_list instead.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #5 from rogerio at rilhas dot com 2010-08-10 22:33 ---
Are you sure this is the way to resolve this issue? I think this will make GCC
an inferior product, as all other compilers I've tested produce correct
results. As GCC sometimes produces correct code (and in such cases it
--- Comment #6 from rogerio at rilhas dot com 2010-08-10 22:35 ---
Let me just add: if you can tell me what options to set to make it always work
that would already be helpful. I noticed that disabling optimizations helps,
but not everytime (adding a lot of local automatic variables to
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-08-10 23:08 ---
correct results.
There is no correct results since you are depending on undefined behavior. It
is not a short coming of GCC but rather the source you are trying to port. The
code is not portable at all. It will
--- 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
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-08-11 00:58 ---
Then, by another well defined attribute (the calling convention) I should be
able to navigate the stack to get the other parameters.
No, the C/C++ standard says doing that is undefined because the array size is
1.
--- Comment #10 from rogerio at rilhas dot com 2010-08-11 01:57 ---
I'm replying now not in the context of the bug (since as I mentioned I must
move on), but just as a conversation between 2 persons. So please don't getting
me wrong for insisting.
The cdecl calling convention on x86-32
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-08-11 03:52
---
The ABI is not of concern here really. The issue comes down to you have:
char *a;
char **b = a;
use(b[1]);
It is undefined what happens when you access b[1]. It does not matter if the
ABI defines that the
58 matches
Mail list logo
