--- Comment #52 from rogerio at rilhas dot com 2010-08-14 13:17 ---
Do you really want me to go away? You are not using the right formula for that.
You know I have a problem and I can't resist. Everytime you post a message
you're just calling me back!
(In reply to comment #49
--- Comment #55 from rogerio at rilhas dot com 2010-08-14 14:31 ---
(In reply to comment #53)
(In reply to comment #52)
(In reply to comment #51)
Look at the page history, it was removed by someone else, probably because
your
comment is badly written and not suitable
--- Comment #56 from rogerio at rilhas dot com 2010-08-14 14:34 ---
(In reply to comment #54)
(In reply to comment #53)
GCC compiles that fine, try it.
Sorry, I forgot my manners, what I meant is...
Why don't you think before shooting off some crap.
So I have shown you talk crap
--- Comment #58 from rogerio at rilhas dot com 2010-08-14 16:02 ---
Why?? Why do you keep calling me back?? I was just going out and I heard the
new e-mail sound! Now I'm going to be late!!
(In reply to comment #57)
Good way to make a convincing argument. You've tried to turn
--- Comment #34 from rogerio at rilhas dot com 2010-08-13 12:14 ---
(In reply to comment #33)
Not really, you could always subtract. However, far pointers gave
predictable addresses, just like C99 says they pointer arithmetic should.
They didn't. If you subtracted far pointers
--- Comment #38 from rogerio at rilhas dot com 2010-08-13 14:47 ---
(In reply to comment #36)
If you include real segmentation
like on 80286, where there's no linear relationship between effective
address and segment+offset, subtraction would have been prohibitively
--- Comment #39 from rogerio at rilhas dot com 2010-08-13 14:48 ---
(In reply to comment #35)
char* p1=(char*)0x3000; // address not pointing to any C-object in the C99
sense
char* p2=(char*)0x4000; // address not pointing to any C-object in the C99
sense
Can GCC users
--- Comment #40 from rogerio at rilhas dot com 2010-08-13 14:53 ---
(In reply to comment #37)
(In reply to comment #36)
I'm not sure you realize just how true that is. But keep going, you're
by far one of the best trolls I've seen in GCC land.
Well, I can easily imagine more
--- Comment #43 from rogerio at rilhas dot com 2010-08-13 16:28 ---
(In reply to comment #41)
You should really adjust your glasses if you want to continue trolling with
the high standards we're used to meanwhile:
What in the words real segmentation like on 286, where there's
--- Comment #44 from rogerio at rilhas dot com 2010-08-13 16:30 ---
(In reply to comment #35)
char* p1=(char*)0x3000; // address not pointing to any C-object in the C99
sense
char* p2=(char*)0x4000; // address not pointing to any C-object in the C99
sense
Can GCC users
--- Comment #46 from rogerio at rilhas dot com 2010-08-13 16:42 ---
(In reply to comment #45)
Congratulations. Are you done now?
What else are you hoping to achieve?
Is this a cry for attention?
No much really. Now it is all up to the community. I just want everyone to know
--- Comment #48 from rogerio at rilhas dot com 2010-08-13 21:16 ---
(In reply to comment #47)
OK, here is the deal:
Since you want this feature so much, I'm sure that everybody would gladly
implement it for you, for - say - measly 5000 EUR. You can then offer this
c-like compiler
--- 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
the address
of function parameters
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rogerio at rilhas dot
--- Comment #1 from rogerio at rilhas dot com 2010-08-12 14:52 ---
Created an attachment (id=21469)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21469action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #2 from rogerio at rilhas dot com 2010-08-12 14:52 ---
Created an attachment (id=21470)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21470action=view)
Compilation script
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #3 from rogerio at rilhas dot com 2010-08-12 14:54 ---
Correction:
If line char buffer[1000]; buffer[0]=0; _is removed then_ GCC then compiles
the code as expected and dif will be 4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #6 from rogerio at rilhas dot com 2010-08-12 15:33 ---
(In reply to comment #4)
Pretty please, before filing further bugs take time and learn C.
The pointer subtraction triggers undefined behavior, because one pointer
points
to one object and the other pointer points
--- Comment #7 from rogerio at rilhas dot com 2010-08-12 15:33 ---
(In reply to comment #5)
ISO/IEC 9899:1999, 6.9.1 Function definitions
9. Each parameter has automatic storage duration. Its identifier is an lvalue,
which is in effect declared at the head of the compound statement
--- Comment #11 from rogerio at rilhas dot com 2010-08-12 16:04 ---
(In reply to comment #8)
(In reply to comment #6)
(In reply to comment #4)
Pretty please, before filing further bugs take time and learn C.
The pointer subtraction triggers undefined behavior, because one
--- Comment #15 from rogerio at rilhas dot com 2010-08-12 16:15 ---
(In reply to comment #14)
I never claimed p1 and p2 have different types. They have the same type.
But the standard paragraph I mentioned says:
When two pointers are subtracted, both shall point to elements
--- Comment #17 from rogerio at rilhas dot com 2010-08-12 16:18 ---
(In reply to comment #12)
Seriously, go away. I'll get far ruder if you're going to open bug reports
worded like this:
(In reply to comment #0)
Don't bother trying to understand why I need the operand to work
--- Comment #18 from rogerio at rilhas dot com 2010-08-12 16:18 ---
You know what? I did a small sample showing this bug to other people. They all
understood it, but not you. They all know what it means C99+cdecl at the same
time. You don't. I'm surprised at your lack of capacity
--- Comment #22 from rogerio at rilhas dot com 2010-08-12 17:24 ---
(In reply to comment #21)
Even without optimization (as the compilation script uses), the program
crashes.
Right, that was the point of introducing the 1000-character buffer. With it it
crashes always
--- Comment #23 from rogerio at rilhas dot com 2010-08-12 17:25 ---
(In reply to comment #19)
Everyone understands it, you're just wrong.
No I'm not, the problem seems to be just to complex for you because you would
have to tie up C99+cdecl to understand, but you don't understand
--- Comment #24 from rogerio at rilhas dot com 2010-08-12 17:50 ---
(In reply to comment #20)
I couldn't resist to comming back (you respond very quickly, kudos!, I'm not
used to that! :-)
Just for fun, I compiled this test case with various levels of optimization.
It works fine
--- Comment #26 from rogerio at rilhas dot com 2010-08-12 18:04 ---
You opened this bug report with insults, what sort of response do you expect?
GCC is too crappy and amateur for your awesome code, so I suggest you stick to
better compilers.
Will do, thanks.
... and sorry for my
--- Comment #29 from rogerio at rilhas dot com 2010-08-12 18:24 ---
(In reply to comment #27)
Oh, this fun. Enjoyable, really! ;-)
Again I couldn't resist! Everytime I'm ready to go away you say something
shocking that I simply can«t resist. Its time for me to admit I have a problem
--- Comment #31 from rogerio at rilhas dot com 2010-08-12 18:32 ---
(In reply to comment #28)
I built your test case with gcc and g++ without optimizations, and it worked
fine.
Just like my script? I noticed that I'm using a not-the-newest GCC version, and
I know that some older
--- Comment #32 from rogerio at rilhas dot com 2010-08-12 18:38 ---
(In reply to comment #30)
you can't even begin to understand how to make a temporary variable an
l-value.
Please look up move constructors and rvalue references. move constructors
are not standard C++ code
--- 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 #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
--- 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
--- 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
--- 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
--- 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
--- 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 #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 #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 #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 #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 whole point
--- 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
--
http://gcc.gnu.org/bugzilla
--- 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)
--
http://gcc.gnu.org
--- 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
segmentation fault
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rogerio at rilhas dot com
GCC build triplet
--- 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 #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
--- 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
--- 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 #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
66 matches
Mail list logo
