--- 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=21448&action=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=21449&action=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=21450&action=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:
W
--- 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 t
--- 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 request
--- 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 argum
--- 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=21452&action=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=21453&action=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
> buffer[2
--- 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 stan
--- 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"
--- 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
#include
void format_indirect(char* dst_buffer, size_t dst_buffer_size_b
--- 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) beca
--- 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 have
--- 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 readi
--- 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
>
--- 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
exten
--- 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 a
--- 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
beginni
--- 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 be
--- 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 a
--- 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 b
--- 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
--- 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
--- 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 t
--- 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 co
--- 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 a
--- 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
--- 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 w
--- 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) disass
--- 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=21462&action=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=21463&action=view)
Snapshot 2 - Inside "format_direct" to show cdecl ABI parameter packing
--
http://gcc.gnu.org/bugzilla/show_bug
--- 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=21464&action=view)
Snapshot 3 - Breakpoint before calling "format_indirect" (showing dump for
$ebp+0x10)
--
http://gcc.gnu.org/bug
--- 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=21465&action=view)
Snapshot 4 - Showing incorrect value for PTR4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
--- 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 wi
--- 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 hap
--- 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
Status|UN
58 matches
Mail list logo
