Created attachment 21469 [details]
Preprocessed file

Created attachment 21470 [details]
Compilation script

Correction:

If line "char buffer[1000]; buffer[0]=0;" _is removed then_ GCC then compiles the code as expected and "dif" will be 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 to different object.
See ISO C99, 6.5.6/9.
In particular, in this testcase the functions are inlined and thus i and strp are just normal automatic variables in main, obviously nothing guarantees how they are laid out in the stack.  But even if it isn't inlined, the behavior would be undefined.

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 that constitutes the function body (and therefore cannot be redeclared in the function body except in an enclosed block). *The layout of the storage for parameters is unspecified.*

(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 to different object.

Pretty pretty please: before you give out such wrong and embarassing answers please take the time to learn the standards and also take the time to learn how to read.

I'm subtracting 2 pointers of the same type. If you knew how to read you would have seen that p1 and p2 are of the same type. Or maybe you just don't know C, but I'm sure you can learn it so that you can be helpful to the GCC team and not waste my time.


> See ISO C99, 6.5.6/9.

I did read it, but it is not the case here, you got it wrong.


> In particular, in this testcase the functions are inlined

Where did you get that idea from??? They are not inlined, you are wrong, check the assembler before imagining what is hapening.

> and thus i and strp
> are just normal automatic variables in main, obviously nothing guarantees how
> they are laid out in the stack.

Wrong, you should learn your C. You could have understood this by yourself if you realized that &i works but &10 doesn't. If you knew your basic C you would know that both "strp" and "i" were passed by value, and so they are not the original in the "main" but instead copies in "bug_example". I'm sure you would want it not to be so, to save face, but you said it now you're stuck with it.


  But even if it isn't inlined, the behavior
> would be undefined.

Wrong again. Undefined by C99 but not undefined by cdecl.

I didn't specify "inline", so GCC should have made cdecl. If it didn't then GCC should not claim to be cdecl. So choose: is it GCC's bug possibility 1 or possibility 2?

(is it really that easy for you to write such wrong answers for everyone to see and keep wasting my time like this??? ... do you think that helps GCC?)

(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 that
> constitutes the function body (and therefore cannot be redeclared in the
> function body except in an enclosed block). *The layout of the storage for
> parameters is unspecified.*

Wrong again. Undefined by C99 but not undefined by cdecl. So choose: is it GCC's bug possibility 1 or possibility 2?

(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 pointer points
> > to one object and the other pointer points to different object.
> 
> Pretty pretty please: before you give out such wrong and embarassing answers
> please take the time to learn the standards and also take the time to learn how
> to read.

Bravo, well trolled.

> I'm subtracting 2 pointers of the same type. If you knew how to read you would
> have seen that p1 and p2 are of the same type. Or maybe you just don't know C,
> but I'm sure you can learn it so that you can be helpful to the GCC team and
> not waste my time.

Please stop trying to use GCC, we'll all be better off.

The parameters contain copies of the argument values (6.9.1#10: "as if by assignment").  The address of a parameter has no meaning.

Ahh, it's just so entertaining.

C99 is a language, cdecl a calling convention.  There is no 'cdecl compiler',
it makes no sense to speak about such a thing.  cdecl is a calling convention
for function written in all kinds of languages.  If you chose to program in C
(and you claim you do), then you have to work by the rules the relevant
language standard imposes on you.  It has been shown multiple times to you
(and you even agree), that what you do is outside of C99.  Countering this
with "but it should still work, because 'cdecl' says so" is invalid reasoning,
a calling convention can't override any limitation the language standard
imposes.

What you want to program in is not C99 (or any C whatsoever), but rather
"Microsofts idea of what a language looking similar to C might look like"-C.

GCC makes no claim to support such language.  It supports C99, and it supports
the cdecl calling convention.  It does not support the language that you
think is C, but isn't.

It might be conceivable that somebody implements a new language frontend
for GCC that would support the Microsoft language without name, as long as
that isn't the case (and you yourself aren't interested in developing such
frontend) the bug reports remain invalid.

(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 pointer points
> > > to one object and the other pointer points to different object.
> > 
> > Pretty pretty please: before you give out such wrong and embarassing answers
> > please take the time to learn the standards and also take the time to learn how
> > to read.
> Bravo, well trolled.
> > I'm subtracting 2 pointers of the same type. If you knew how to read you would
> > have seen that p1 and p2 are of the same type. Or maybe you just don't know C,
> > but I'm sure you can learn it so that you can be helpful to the GCC team and
> > not waste my time.
> Please stop trying to use GCC, we'll all be better off.

Oh and that will make your colleague Jakub right about p1 and p2 be of diferent types? Does it make his answer intelligent? Sure, whatever you say, I'll follow your recommendation.

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 as stated in
> C99, or why I need the code to be cdecl compliant, that is too complicated for
> you and it would just confuse you.

>diferent types?

He did not say different types but different objects.  There is a difference between objects and types.  This comes down to:
&a - &b being undefined in C90/C99/C++98/C++03/C++0x because a and b are two different objects.

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 of the same array object, or one past the last element of the array object"
That is not the case in your testcase, strp and i are different objects.

(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 of the same
> array object, or one past the last element of the array object"
> That is not the case in your testcase, strp and i are different objects.

char* p1=random_address();
char* p2=another_random_address();

p1-p2 is always well defined, no matter to which objects they point to. After the subtracion they will point to objects of the same type (char's). So, you don't know your C nor C99 (we are reading it wrong).

(In reply to comment #15)
> 
> char* p1=random_address();
> char* p2=another_random_address();
> 
> p1-p2 is always well defined, no matter to which objects they point to.


No. No it isn't. It really isn't.

(In reply to comment #6)
> 
> Pretty pretty please: before you give out such wrong and embarassing answers
> please take the time to learn the standards and also take the time to learn how
> to read.

Maybe you should practice what you preach.

(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 as stated in
> > C99, or why I need the code to be cdecl compliant, that is too complicated for
> > you and it would just confuse you.


... ooooo... now you got me scared. I will just go away before you call me C-ignorant or something really insightful like that.

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 for uderstanding. Well, as long as you are proud of yourselves then that is what really matters, right? Good luck with that.

Everyone understands it, you're just wrong.

Just for fun, I compiled this test case with various levels of optimization.  It works fine without optimization or with -O1, but segfaults at -O2 or -O3.

That indicates that the program only works by coincidence, not by design - you've made assumptions about how GCC will interpret your sources, and those assumptions are wrong.  In this case, your assumption is that "bug_example_2" will always be a separate function, and will always be called as a separate function, and thus that you can assume some knowledge of the internals of the stack layout.

The C language does *not* require that a function which is called, be called as a separate function, only that the semantics of the call be the same as far as the C language requires.  The C language allows GCC to implement that function call in any way it chooses - and GCC chooses to implement it without actually doing a function call, but by copying the function body to the callee.  At least, it does when optimizing.  Without optimization, it *happens* to do what you expect.  It will also do what you expect if bug_example_2 and bug_example are in separate source files - *then* the "cdecl" standard you refer to applies, because cross-object calls are limited by the compatibility standards.

However - if you use gcc to link as well, gcc has the option of optimizing those calls *also*.

So, GCC is "cdecl" compliant because *if* there's a function call, *then* the *stack* is laid out the same.  However, the "cdecl" standard does *not* require that your program work, because C allows the optimizer to avoid the actual function call completely when the callee and caller are in the same scope.

Note: you can tell gcc to not inline a function with __attribute__((noinline)) in which case a call to it is always an actual call to it, but it would be easier to just use the standard methods for accessing parameters so that it *always* works.

Also, with full optimization enabled, your code crashes with MSVC also.
Please file a bug report with Microsoft.

Even without optimization (as the compilation script uses), the program crashes.  To be concrete about what's going wrong based on what the assembly code actually looks like (GCC version Ubuntu 4.4.3-4ubuntu5):

bug_example:
    pushl    %ebp
    movl    %esp, %ebp
    subl    $1048, %esp         # space for buffer
    movl    8(%ebp), %eax       # move string elsewhere
    movl    %eax, -1020(%ebp)
    movl    %gs:20, %eax        # stuff for stack checking
    movl    %eax, -12(%ebp)
    xorl    %eax, %eax
    movb    $0, -1012(%ebp)
    leal    12(%ebp), %eax      # address of i to stack
    movl    %eax, 4(%esp)
    leal    -1020(%ebp), %eax   # address of (copied) strp to stack
    movl    %eax, (%esp)
    call    bug_example_2
    movl    -12(%ebp), %eax
    xorl    %gs:20, %eax
    je    .L6
    call    __stack_chk_fail
.L6:
    leave
    ret
    .size    bug_example, .-bug_example

You are assuming that in `bug_example' that the parameters passed to `bug_example_2' must be the addresses of those variables *as they were passed on the stack*.  This is certainly one way of implementing it, but it is not mandated by the standard (as comment #9 points out).

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

>  To be concrete about what's going wrong based on what the assembly
> code actually looks like (GCC version Ubuntu 4.4.3-4ubuntu5):
> bug_example:
>     pushl    %ebp
>     movl    %esp, %ebp
>     subl    $1048, %esp         # space for buffer
>     movl    8(%ebp), %eax       # move string elsewhere
>     movl    %eax, -1020(%ebp)
>     movl    %gs:20, %eax        # stuff for stack checking
>     movl    %eax, -12(%ebp)
>     xorl    %eax, %eax
>     movb    $0, -1012(%ebp)
>     leal    12(%ebp), %eax      # address of i to stack
>     movl    %eax, 4(%esp)
>     leal    -1020(%ebp), %eax   # address of (copied) strp to stack
>     movl    %eax, (%esp)
>     call    bug_example_2
>     movl    -12(%ebp), %eax
>     xorl    %gs:20, %eax
>     je    .L6
>     call    __stack_chk_fail
> .L6:
>     leave
>     ret
>     .size    bug_example, .-bug_example
> You are assuming that in `bug_example' that the parameters passed to
> `bug_example_2' must be the addresses of those variables *as they were passed
> on the stack*.  This is certainly one way of implementing it, but it is not
> mandated by the standard (as comment #9 points out).

You are absolutelly right, I fully agree that a non-cdecl conformant GCC would not need to pass parameters on the stack. It only has to pass parameters on the stack (in a very well-defined way) if it claims to be cdecl-compliant. But even with the cdecl specifier in the source the generated assembly code is wrong. Hence a bug.

Hadn't you realized yet that that is my point from the start????

(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 it because you don't know "cdecl language" (this still makes me laugh!) and so you don't get out of your little C99 box (which makes you lose sight of the big picture).

char* p1=random_address();
char* p2=another_random_address();

Any compiler that does not predictably compute p2-p1 is a piece of crap. You can twist C99 all you want, but whenever p2-p1 is left to some undefined criteria of the compiler then it is just an absolute piece of crap. Period. That is why no compiler leaves this indefined, even GCC (apparently it was just luck). This should be enough for you to see you are not getting C99 right, because following what you say would create crappy compilers. Feel free to try and prove they would not be crappy.

Even if you could convince me of your interpretation of C99 and p2-p1 were not well defined, you would still have to explain why "&strp" is not 4 bytes before "&i" (not subtracting, just looking at their disassembled addresses). This is the big picture that you do not understand, you just keep deflecting.

... while we discuss GCC still doesn't return the correct address for "&strp".

So, let me just summarize by saying I was so so so so wrong to expect GCC to have returned the address that my little brain expected to result from the combination C99+cdecl. Of course I was wrong and you were right, which makes me stupit and you smart.

Meanwhile everyone else knows that "if it compiles in GCC and executes correctly then it compiles and executes correctly in any other compiler"... can you deduce why? Does it make you proud? ... hint: which do you think is the compiler with the most reduced capabilities that serves as a baseline for your code? Would you like to keep GCC at this low end of the spectrum? Good, just keep on insisting on your interpretation of C99.

http://en.wikipedia.org/wiki/GNU_Compiler_Collection

"In 2007, GCC received criticism from one OpenBSD developer who complained that GCC is mostly developed by companies, that it is large, buggy, slow, and that it generates poor code,[31][not in citation given][32] and who also dislike v3 of the GNU GPL.[33] The OpenBSD project and FreeBSD projects, respectively, are experimenting with replacing GCC with the Portable C Compiler[33] and Clang/LLVM.[34] The NetBSD and DragonFlyBSD projects have commented that on replacing GCC, they have explored various compiler replacements but have no solid answers.[35]" (I've checked the references, they are fine!!)

Does it have anything to do that you dismiss people who find and show you bugs? Maybe you do a good job when you quickly send them away after stamping it with "non-conformant", I don't know, but I expected a little more interest on your part to make GCC better. I would be open to anything, including something along the lines of "ok, it is not a bug, but we will consider this as a feature request"... but not even that.

I'll come back some day (be afraid!! :-) ) with a list of compilers tested to see how many produce correct results for this bug report. For now in 4 compilers tested (2 from Microsoft) 3 of them do the job correctly and GCC is the only one that doesn't. Oopss...! I meant: GCC is the only one to have correctly interpreted C99, the other 3 got it wrong and let me get the addresses of the parameters as I wrongfully expected. And let me subtract them predictably. This surelly proves you are very insightfull and that you know C99 better than anyone else.

Gone, sorry for any inconvenience.

(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 without optimization or with -O1, but segfaults at -O2 or -O3.

The script I sent you does not request optimizations and segfaults.

> That indicates that the program only works by coincidence, not by design -
> you've made assumptions about how GCC will interpret your sources, and those
> assumptions are wrong.  In this case, your assumption is that "bug_example_2"
> will always be a separate function, and will always be called as a separate
> function, and thus that you can assume some knowledge of the internals of the
> stack layout.

When I don«t request optimizations my interpretation is right. A function declaration (that doesn't specifically request inline) is a function. I don't know if C99 says it (probably does, in a C-sense function), but cdecl does.

> The C language does *not* require that a function which is called, be called as
> a separate function, only that the semantics of the call be the same as far as
> the C language requires.  The C language allows GCC to implement that function
> call in any way it chooses - and GCC chooses to implement it without actually
> doing a function call, but by copying the function body to the callee.  At
> least, it does when optimizing.  Without optimization, it *happens* to do what
> you expect.

Compile it like I did in the script (without optimizations) and see it fail.

>  It will also do what you expect if bug_example_2 and bug_example
> are in separate source files - *then* the "cdecl" standard you refer to
> applies, because cross-object calls are limited by the compatibility standards.
> However - if you use gcc to link as well, gcc has the option of optimizing
> those calls *also*.
> So, GCC is "cdecl" compliant because *if* there's a function call, *then* the
> *stack* is laid out the same.  However, the "cdecl" standard does *not* require
> that your program work, because C allows the optimizer to avoid the actual
> function call completely when the callee and caller are in the same scope.

Incorrect, code should not be optimized if I don't request it. If I do I have to live without cdecl compliance, obviously, as I don't know of any compiler that has an option like "optimize_as_possible_but_keep_cdecl_always". My point is for non-optimized code, and that is why I included the scrip I used to build it.

> Note: you can tell gcc to not inline a function with __attribute__((noinline))
> in which case a call to it is always an actual call to it, but it would be
> easier to just use the standard methods for accessing parameters so that it
> *always* works.

Agreed. But I'm determining the addresses of the parameters just to check GCC's conformity, remember? So don't you worry about how easy the code is for me, I will deal with that.

I just tried the attribute and didn't make any difference in the code, and is still not cdecl. I'm sure it is not a bug in GCC though...

> Also, with full optimization enabled, your code crashes with MSVC also.

Right. As explained, this bug report is about non-optimized code. I also didn't expect Microsoft's code to not crash if optimized (nor tried it until your comment).

I don't think I ever mentioned optimizations in this bug report, I did it in the "variable parameters" bug report bucause that was how I initially got it to crash and had no way to report it to you (it crashed without optimizations in a larger program that I could not send to you), but I later sent you a full report (with snapshots and all in comment #51) a non-optimized version that crashed. Here I could easilly show it to crash when not optimized, and so I could live with disabling optimizations to get the addresses to be returned properly.


> Please file a bug report with Microsoft.

No need. Their code *NEVER* crashes if I don't request optimizations.

This is it, I must resist! Bye!! :-)

(In reply to comment #23)
> Maybe you do a good job when you quickly send them away after stamping it with
> "non-conformant", I don't know, but I expected a little more interest on your
> part to make GCC better. I would be open to anything, including something along
> the lines of "ok, it is not a bug, but we will consider this as a feature
> request"... but not even that.

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.

 

> 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 "opening lines", I was very pissed off that after a great deal of work making a full report you didn't see that problem was not related to the variable arguments and it seemed to me that you were not even bothering to to read it, and kept dismissing me as "trying to do non-conformat things". That is what motivated me to isolate the problem for this bug report, and I am sorry I was unable to "put on a happy face", my bad.

Oh, this fun.  Enjoyable, really! ;-)

So, you admit that MSVC does in fact "miscompile" your perfectly fine cdecl code, if you request optimization from it?  How bad is that of them?
Terrible!  I would consider creating a bug report with them, because if they
miscompile your code with optimizations it must surely be their bug.  After
all optimization is a process of transforming a valid program into another
program that behaves exactly the same, hence if they optimize your valid
program into a crasher, what else could it be than a bug in their compiler?

I mean, really.  They are supposed to provide a commercial grade compiler.
How can it be that they force you to deactivate optimization options
(and hence live with slow runtime) just so that your valid cdecl program
doesn't crash?

One side remark about your p2-p1 claim:
> char* p1=random_address();
> char* p2=another_random_address();
> 
> Any compiler that does not predictably compute p2-p1 is a piece of crap. You
> can twist C99 all you want, but whenever p2-p1 is left to some undefined
> criteria of the compiler then it is just an absolute piece of crap. Period.

You obviously never used segmented platforms (old DOS was such a thing,
but there are others more recent, e.g. Cell with PowerPC is similar in this
respect).  On those it was valid only to sunstract pointers from each other
when they pointed into the same segment.  Because the pointer difference type
was a 16 bit type, whereas the pointers could address 1MB of memory (hence 
effectively 20 bit).  If you do the math you'll see that it's impossible
to map all 2^20 possible differences between pointers (unsigned 2-completement
20-bit arithmetic, otherwise 2^21 differences) into just 16 bit.  So yes,
on those platforms it really was impossible to substract two arbitrary
pointers.

C (the language) reflects such constraints.

With complete trust in your incapability to grok these concepts. but hats
off to a capable troll,
Michael.

I built your test case with gcc and g++ without optimizations, and it worked fine.  I could only get it to fail with gcc/g++ by optimizing, but then, I could get it to fail with MSVC by optimizing.  Seems to me, gcc and MSVC are doing the same thing, or you have some modified version of gcc that is not acting the same way as the official version.

Also, please provide an official spec for this "cdecl" you keep referring to.

(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! :-)

> So, you admit that MSVC does in fact "miscompile" your perfectly fine cdecl
> code, if you request optimization from it?

Yes.

>  How bad is that of them?

Not perfect, but still better than GCC, because at least I can get it to work.

> Terrible!

... noooo... that's just your jealousy talking because you can't even begin to understand how to make a temporary variable an l-value... how can someone be defending a compiler that never conforms (GCC) to one that conforms if I don't request it to optimize? That's just bad logic. It's not my intention to insult you, but the observation itself lacks any underlying logic.

>  I would consider creating a bug report with them, because if they
> miscompile your code with optimizations it must surely be their bug.

No, optimizations take away room for assumptions. That's why GCC can optimize for(i=0; i<strlen(sp); i++). What??? GCC didn't call strlen() every time? How stupid! No, you are just lacking logic. Drink something with vitamins and get out more, it will do you good.

>  After
> all optimization is a process of transforming a valid program into another
> program that behaves exactly the same, hence if they optimize your valid
> program into a crasher, what else could it be than a bug in their compiler?

Read my strlen() example. That shows you are wrong. You "invented" that definition, you can't really back it up otherwise strlen() would have to be called every time.

> I mean, really.  They are supposed to provide a commercial grade compiler.
> How can it be that they force you to deactivate optimization options
> (and hence live with slow runtime) just so that your valid cdecl program
> doesn't crash?

Yup, money can only buy so much. No money can buy you alittle bit less.

> One side remark about your p2-p1 claim:
> > char* p1=random_address();
> > char* p2=another_random_address();
> > 
> > Any compiler that does not predictably compute p2-p1 is a piece of crap. You
> > can twist C99 all you want, but whenever p2-p1 is left to some undefined
> > criteria of the compiler then it is just an absolute piece of crap. Period.
> You obviously never used segmented platforms (old DOS was such a thing,
> but there are others more recent, e.g. Cell with PowerPC is similar in this
> respect).

Yes I did work with those platforms. Remember the "far" qualifiers? Remember what they were for? They were invented to make you, again, write something wrong.

However, as parameters to functions, they were always in the same segment, so the subtraction was always valid. C99 cannot back this up though, it was just the way things were made back then. Maybe GCC inherited too much from those days.


>  On those it was valid only to sunstract pointers from each other
> when they pointed into the same segment.

Not really, you could always subtract. However, far pointers gave predictable addresses, just like C99 says they pointer arithmetic should. Go and read C99 about the "far" qualifier so that you can see why it was not smart of you to talk about DOS.

Still, on every segmented platform, the subtraction of the addresses of parameters is always valid, as parameter will be all placed on the same stack. And if some parameters had "far" qualifies and other not then the compilers would warn you about it so that you could requalify them.

Don't talk about what you don't know, you clearly know much less about the old days than me. Stick to C99.

>  Because the pointer difference type
> was a 16 bit type, whereas the pointers could address 1MB of memory (hence 
> effectively 20 bit).  If you do the math you'll see that it's impossible
> to map all 2^20 possible differences between pointers (unsigned 2-completement
> 20-bit arithmetic, otherwise 2^21 differences) into just 16 bit.  So yes,
> on those platforms it really was impossible to substract two arbitrary
> pointers.

No. Pointers of the same type, with the same qualifiers, were always subtractable. Don't invent, it will just make you wrong. The addresses of parameters on the stack would always be near (16-bit), so subtraction would always be well-defined.

> C (the language) reflects such constraints.

Not really, no. Or can you back up your claims with an old standard applycable 30 or 40 years ago? I'm sure you can't. I don't even know if cdecl was well defined back then, do you?

> With complete trust in your incapability to grok these concepts. but hats
> off to a capable troll,
> Michael.

Its is amazing how foast you take your self out and crash head-on into a wall. And be proud of it. But you are right, this is fun. Keep on sending your errors, inventions, inconsistencies, and mistakes, and I'll keep on correcting them. Then you deflect and try to pretend that you said smart things and send me a bunch of errors again. We could make a really fun game out of it.

>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 but the C++ standard committee decided to add rvalue references instead.  Please read the history of those and then come back when you understand what you are talking about.

(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 version 3.xxx didn't have the problem (a few years ago). Maybe it is something changed in the most recent versions?

>  I could only get it to fail with gcc/g++ by optimizing, but then, I
> could get it to fail with MSVC by optimizing.  Seems to me, gcc and MSVC are
> doing the same thing, or you have some modified version of gcc that is not
> acting the same way as the official version.

I'm sorry, but I'm new to Linux, I'm not sure if the GCC I'm using got "tweaked" in any way. It came with Ubuntu, but I don't know if it got upgraded with Code::Blocks. I thought that "-save-temps" would provide you with that information, didn't it? How can I get such information?

> Also, please provide an official spec for this "cdecl" you keep referring to.

Sorry, I did send you one in my variable arguments report and I forgot to send it here olso. http://sco.com./developers/devspecs/abi386-4.pdf, see "Figure 3-48: C Stack Frame". It is not a standard, as I'm sure you know, but it is a well-defined concept.

(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 but the C++ standard committee decided to add rvalue
> references instead.  Please read the history of those and then come back when
> you understand what you are talking about.

If I were to follow your logic I would, because acording to your logic a parameter doesn't have an address. But C99 doesn't limit this in any way, does it? The & get the address of the item, period. So I don't need to go look up unrelated topics, you are the one who should look up address of parameter.

function(class_name(initializer))

... should work if class_name(initializer) were an lvalue. One of you posted a standard for that. Microsoft can get the address of class_name(initializer), hence Microsft is capable of looking at class_name(initializer) as an l-value. How Microsoft does it is not important, they do it and GCC doesn't. So Microsoft can compile all these equivalently:

int a=10;
function(i)
function(int(20))
function(class_name(initializer))

I don't really care what GCC could do to make class_name(initializer) an l-value, but if "move constructors" are a good way to go at it then do it. As C99 doesn't specify this GCC is happy and doesn't need the feel to change. And, so, I don't call it a bug, just a very nice feature that it is missing.

> Don't talk about what you don't know, you clearly know much less about the
> old days than me.

Well, I'll grant you that you know many wondrous and astounding "facts",
indeed.  Let me just answer one random sentence out of your answer, just to
keep it funny:

> 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 that pointed into different
segment, the segment difference was ignored.  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 expensive to
implement anyway.  And you still wouldn't get around the size limitation
of ptrdiff_t that was 16bit.

And of course the subtraction of addresses of parameter is always meaningless
in C, segmented or not, as pointed out multiple times.  With or without cdecl.

Or, another one:

> No, optimizations take away room for assumptions.

Um, huh?  That's completely backwards.  Optimizations make _use_ of the
assumptions/guarantees that the relevant standard gives you.

> Drink something with vitamins and get out more, it will do you good.

That is certainly a good advise.  I OTOH would advise you to possibly drink
more alcohol.  Much more.  Really much much more.

> Go and read C99 about the "far" qualifier so that you can see why it was
> not smart of you to talk about DOS.

C99 doesn't mention such qualifiers.  I said that the restrictions in the
standard (in this case which pointers can be compared/subtracted) have their
reason in wanting to support all imaginable memory models.  Nevertheless
those restriction apply to _all_ implementations, even those that have trivial
memory models, like a flat address space.

(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 that pointed into different
> segment, the segment difference was ignored.  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 expensive to
> implement anyway.

That's just ignorance on your part (nothing new, I guess I'm becoming used to that). You are saying things that you don't know. You said that without even knowing if there were any compilers back then that didn't do what you said. You just took your personal experience with some crappy compiler and generalized it for everyone. Wrong.

What you don't know is that when you subtracted far pointers the compiler generated the code to change seg16:ofs16 into abs20. What you think is "prohibitively expensive" would come down to 4 instructions or something like that (2 shifts, 2 additions). But lets say 10. Is that "prohibitively expensive"?? If the user requested a pointer difference you would be happy as a compiler developer to just not compile (or produce an incorrect difference) instead of generating 10 machine instructions? Or 20?

A compiler should NEVER EVER EVER refuse to compile (or compile bad code) because the resulting number of instructions is large. Your comment and opinion thus don't deserve any respect because we are defending the way to do a bad compiler. That claim is not just wrong, it is dumb. I'm not trying to offend you, I'm sure you are not dumb, but you let a dumb comment slip out.

Anyway, again you are just plain wrong. The compilers I used back then did this operation well. In those days there were no real standards that developers would generally follow, and programmers used to rely on what they knew about a compiler. So I guess you might have used some crappy one that failed miserably at pointer arithmetic, and based your whole opinion that it is beller to compile bad arithmetic or not compile at all than to add 10 instructions to the code.

Your ignorance is in not knowing that segmented addresses were already being abstracted to C programmers by mid-range compilers. I remember this being already done on 8088 compilers, abstraction of the underlying hardware was something every C compiler strived to do. No compiler I knew of didn't do an operation correctly because it had to generate 10 instructions or 20. or a loop. So you stated something as an absolute truth but failed to see that one single exception would prove you wrong. So you you threw yourself head on against the wall again.

But don't worry, I think I know your type fairly well. You will probably just get right back up on the horse, shake it all off, forget about what you did wrong, and start anew with some other wrong statement. I'm basing this on your track record in our conversations, where almost 100% of your claims are wrong or miss the point. That is just impressive. In case I'm wrong about you my apologies.


>  And you still wouldn't get around the size limitation of ptrdiff_t that was 16bit.


What the hell are you talking about????? I personally disassembled code in the late 80's to see how the compiler implemented 32-bit arithmetic on a 286. It did, and it did it well. You weren't able to go beyond 16 bits in the 80's? Or are just making this stuff up? I'm sure you are making it up, on an 8-bit PIC I have written assembly code to do 32-bit shift-add and it uses up something like 12 instructions or so. Not hard at all. Not "prohibitive" at all.

Again: you wished you were right, but you are wrong. You think you known, but you don't. But are you careful? No, you just keep throwing yourself against a wall. And you don't seem to realise that that is becomming a recurring pattern for you. Keep it up, it is fun to watch.


> And of course the subtraction of addresses of parameter is always meaningless
> in C, segmented or not, as pointed out multiple times.  With or without cdecl.


Yup, and multiple times you have been wrong. The cute C99 box you live in doesn't let you see beyond that. But &param is not meaningless if the compiler adheres to cdecl, I've shown that numerous times, you are just unable to see (your bad).

operation 1 - place parameters as cdecl (try to learn something here please, it is important that you don't run away and hide inside C99):

push param3 to address X+8 on the stack
push param2 to address X+4 on the stack
push param1 to address X on the stack
call function

function:
get address of param1: MUST BE X!!!!!
get address of param2: MUST BE X+4!!!!!
get address of param3: MUST BE X+8!!!!!

But I guess you will just keep on losing yourself here because cdecl is outside of C99. And if you try to leave the C99 box your brain crashes and you just have to run back inside C99 and miss the point again. And shoot out some crappy malformed argument about why I am oh just so wrong.

Colleagues of yours did confirm it, so that "With or without cdecl" is just you making it up, not the truth. Do you want me to quote your colleagues? I think it would look bad on you if I did that, but I will if you like.


> Or, another one:
> > No, optimizations take away room for assumptions.
> Um, huh?  That's completely backwards.  Optimizations make _use_ of the
> assumptions/guarantees that the relevant standard gives you.


c0=get_total_instructions_from_cpu();
for(i=0; i<strlen(big_string); i++) call_big_function();
c1=get_total_instructions_from_cpu();
selected_country=c1-c0;
while(1) launch_missile_to(selected_country);

You've developed, compiled it, and everytime you ran it it always bombed my country, and you were happy. Then you optimized and it started bombing your country. And you didn't know why. You simply didn't know. You didn't understand, because you believe with all your heart that the compiler is supposed to do "functionally equivalent" code, and that that equivalency is guaranteed. You push your brain to the max, and you strugle and you strugle and you strugle and go up and down on C99 and there is nothing there to tell you what went wrong!

I do understand why. The compiler will make *a number of assumptions* about what you want to do. And most of the times it will be right to do so. One of the assumptions that the compiler makes is that you (as a programmer) don't care about the number of CPU instructions executed. The compiler will be right to assume so, because 99.99999% of all programmers really don't care about the number of instructions executed, or, in the very least, they want the number to be as low as possible.

But there will come some guy that really needs to know the number of CPU instructions because he needs to synchronize the something to the whatever, and so the compiler will not generate "functionally equivalent" code.

By definition, optimized code is not equivalent. So "functionally equivalent" is something that you just made up and defined poorly because you don't know what the function will be. This particular function needs the number of CPU instructions executed, so this particular function will not be optimized to another "functionally equivalent" function.

You think you know what "functionally equivalent" because you didn't step out of your C99 box (which doesn't specify what functions people will want to do in the whole wide world) but that just makes you wrong and careless in your claims. And so I keep proving you wrong very easily, because in the real world a function is something with a meaning that you cannot possible imagine that you know everything about.

So you should be more careful because all this is leaving a permanent record with your name on it for everyone to see how consistently wrong you always are and how you don't think things through before you write something. Worse, the GCC is bound to your claims, so everyone there should help you not make such mistakes repeatedly.

I'm one of those guys: I want to get addresses of parameters. The compiler expects that no one cares about the addresses of parameters (and it will be right to do so 99.9999999% of the time), so it may feel free to change those addresses when I ask it to optimize. (it shouldn't if I explicitly used the cdecl keyword, but unfortunatelly many programers abused it so now the compiler cannot optimize a lot from many libraries if it doesn't ignore cdecl when optimizing).

So it would be dumb of me to get the addresses of parameters with optimized code, like it would be dumb for the bomber to optimize his bombing code when he relies on the number of instructions. He should know the optimizing compiler could change the number of instructions and so should not optimize his code. So I know that optimizing may make code not comply to cdecl anymore and, so, the addresses of parameters may come out wrong.

Clear enough for you now? I think I've reached the limit of what words can express, as is all fairly obvious and I don't see why you missed it.

BTW: in my "real world" applications built with Microsoft's compilers I was always able to optimize the variable parameters functions and the compiler still gave me the correct addresses. To prove this you can compile the code I sent you in MS VS 2008, with optimizations on, and confirm by yourself that it works. I've made many variations of it over the years and it never failed me, so much so I trust it implicitly these days.

Maybe Microsoft has special code in the optimizing compiler to handle the specific case of variable parameter arguments in a cdecl-conformat way always, who knows? Or maybe they suspected that those types of functions could likelly be used by users to access parameters directly and so they needed to respect cdecl even when optimized.

So, the conclusion, is that MS made the right option to, at least, not mess up cdecl in variable argument functions, and another right option of not optimizing if the user didn't request it. By comparison GCC made zero good options here.


> > Drink something with vitamins and get out more, it will do you good.
> That is certainly a good advise.  I OTOH would advise you to possibly drink
> more alcohol.  Much more.  Really much much more.


Why? So that we can be on the same page?? No, not me, I don't want to write nonsense on the web, I prefer to be clear headed. One never knows when stuff one wrote on the net will come back and bite one in the ass!!


> > Go and read C99 about the "far" qualifier so that you can see why it was
> > not smart of you to talk about DOS.
> C99 doesn't mention such qualifiers.


Exactly. Don't tell me you went there looking for it!! I was being sarcastic as a short way to tell you that you were on your own for this discussion, C99 would not help you.


>  I said that the restrictions in the
> standard (in this case which pointers can be compared/subtracted) have their
> reason in wanting to support all imaginable memory models.


And in your mind a C standard cannot abstract from a sgmented memory model. Right. I know what you think, I'm just glad it is not true, as it is very confortable for me to have compilers abstract me from the underlying architecture and always return valid and correct pointer diferences no matter what. I'll keep on trying out compilers and platforms and will let you when I find one combination of those that does what you say. I will then throw it away, as a piece of crap that it will be, but I'll come back to let you know that I found one.


>  Nevertheless
> those restriction apply to _all_ implementations, even those that have trivial
> memory models, like a flat address space.


Just to make sure you leave a useful contribution to the world (and because you already lost track of the original issue) please tell me:

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 trust that p2-p1 will always return a predictable and well defined integer value of 0x1000 on any platform with 16-bit or more that GCC currently supports or that will come to support in the future?

[ ] Yes
[ ] No

Please think thoroughly before you answer, as I will feel free to use your answer as GCC-binding in any public forum I like.

As you might have guessed by the tone of this comment I was wrong to think this would be a fun game. I'm begining to feel your comments don't deserve any respect. I'll come back to see if you answered "yes" or "no" to the question above. If you answered correctly I'll just leave you alone then and won't try to backtrace our conversation to my initial comment to show you I was right from the start about the pointer arithmetic and that you were wrong to not look beyond C99. If you select the wrong answer you will see your name posted on a lot of public forums binding GCC to what you said. Sorry if I crossed any lines with you, I tried hard not to be disrespectful (but it is a very difficult task!!).

> 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 trust that p2-p1 will always return a predictable and well
> defined integer value of 0x1000 on any platform with 16-bit or more that GCC
> currently supports or that will come to support in the future?
 
[ ] Yes
[x] No

> > 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
> > expensive to implement anyway.

> What you don't know is that when you subtracted far pointers the compiler
> generated the code to change seg16:ofs16 into abs20.

What in the words "real segmentation like on 286, where there's no linear relationship between effective address and segment+offset" was unclear to
you to expect that abs20==seg16*16+ofs16?  The "prohibitive expensive"
referred to the necessary lookup of the base in the LDT/GDT that would have
been required for every far pointer subtraction.

> > And you still wouldn't get around the size limitation of ptrdiff_t that
> > was 16bit.

> What the hell are you talking about????? I personally disassembled code in
> the late 80's to see how the compiler implemented 32-bit arithmetic on a
> 286. It did, and it did it well. You weren't able to go beyond 16 bits in
> the 80's?

Did I say that?  Let's see: "size limitation of ptrdiff_t that was 16bit".
Nope.  I didn't.  The point being that if ptrdiff_t is only 16 bit, then
no matter how fantastically capable the compiler was in emitting 32bit
arithmetic, the result of subtracting to char pointers pointing more than
64KB (or in fact 32KB) apart would not fit into a ptrdiff_t.

> No, not me, I don't want to write nonsense on the web,

Maybe you don't necessarily want to.  But ... , well, there we are.

> I prefer to be clear headed. One never knows when stuff one wrote on the
> net will come back and bite one in the ass!!

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.  Much better than
Pizarro.

(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 funny things to do, some even summer-specific, but indeed, can be interesting, from a psychological point of view, I mean ;) 

(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
> > > expensive to implement anyway.
> > What you don't know is that when you subtracted far pointers the compiler
> > generated the code to change seg16:ofs16 into abs20.
> What in the words "real segmentation like on 286, where there's no linear
> relationship between effective address and segment+offset" was unclear to
> you to expect that abs20==seg16*16+ofs16?  The "prohibitive expensive"
> referred to the necessary lookup of the base in the LDT/GDT that would have
> been required for every far pointer subtraction.

From wikipedia:

"Rather than concatenating the segment register with the address register, as in most processors whose address space exceeded their register size, the 8086 shifted the 16-bit segment only 4 bits left before adding it to the 16-bit offset (16·segment + offset), therefore producing a 20-bit external (or effective or physical) address from the 32-bit segment:offset pair."

So there you go: the relation between effective abs20 address and seg16:ofs16 pair. And it is a linear relation: abs20=K*seg+ofs establishes a linear relation. Check your algebra, and check x86 operation before saying "random stuff".

Can you guess how tricky it is for a compiler to get an effective abs20 address out of a seg:ofs pair?

abs20=seg*16+ofs (voilá! ...magic!!)

What are you dreaming about LDT/GDT? Do you think you need any of that to get an abs20 from a seg16:ofs16 pair? Or maybe you think that a far qualifier would noke the compiler carry seg16 and ofs16 everywhere it went? You just made that stuff up again. Michael Michael Michael: what did I tell you about making stuff up? You don't need to prove to anyone that you are creative, will all know that by now.

... and if Wikipedia is not good enough for you then you can learn about segmentation and how to compute effective addresses in many places. All will teach you what Wikipedia shows. I would teach you if you paid me. No, scratch that: I woudn't, so I'll just leave you alone on this one.


> > > And you still wouldn't get around the size limitation of ptrdiff_t that
> > > was 16bit.
> > What the hell are you talking about????? I personally disassembled code in
> > the late 80's to see how the compiler implemented 32-bit arithmetic on a
> > 286. It did, and it did it well. You weren't able to go beyond 16 bits in
> > the 80's?
> Did I say that?  Let's see: "size limitation of ptrdiff_t that was 16bit".
> Nope.  I didn't.  The point being that if ptrdiff_t is only 16 bit, then
> no matter how fantastically capable the compiler was in emitting 32bit
> arithmetic, the result of subtracting to char pointers pointing more than
> 64KB (or in fact 32KB) apart would not fit into a ptrdiff_t.

The code I used to do was somthing like "long dif=ptr2-ptr1" (long was most often 32-bit back then). Why the hell did you bring "ptrdiff_t" to the conversation? I didn't get it, honestly. But if you brought it was was surely to show me that there was no point in doing 20-bit arithmetic because I would not be able to fit that result anywhere, right? Maybe not, you lost me with the whole "ptrdiff_t" that you decided to bring into the conversation.


> > No, not me, I don't want to write nonsense on the web,
> Maybe you don't necessarily want to.  But ... , well, there we are.


Yup. You have still to make one valid claim, and I've been easily shooting you down everytime. And I back it up, isn't that an amazing concept? You should try it sometime.


> > I prefer to be clear headed. One never knows when stuff one wrote on the
> > net will come back and bite one in the ass!!
> 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.  Much better than
> Pizarro.

... is troll code for "guy who doesn't forgive any false claims and repeatedly shoots down and squashes people who do that repeatedly like a mean son of a <insert_repulsive_animal_here>" that he is?

In that case thanks! :-)

(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 trust that p2-p1 will always return a predictable and well
> > defined integer value of 0x1000 on any platform with 16-bit or more that GCC
> > currently supports or that will come to support in the future?
> [ ] Yes
> [x] No


Thanks. The comunity will be alerted to this. I'll get back to you when your name is in some famous place associated with this claim.

(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 funny things to do, some even summer-specific,
> but indeed, can be interesting, from a psychological point of view, I mean ;) 

Possibly... I'm on vacation, so this morning I just played a little bit of Half Life 2 on the console (yes, keep the wise cracks to yourself, I know I'm severely outdated when it comes to video games!). Anyway, after about half an hour of killing zombies and shooting down bad guys I got bored. Turned on the PC and THERE WAS MICHAEL!!!! It is easier and more entertaining to shoot him down than zombies with a 5 year old AI.

Then I went for a swim, had lunch with the family, and the Sun got to strong to be outside. What else is there to do?? I know!!! Let's check on Michael again!! :-)

So you see: I do have a problem. I will seek help. Promise. :-)

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 no linear
> > relationship between effective address and segment+offset"

So, I think it's pretty clear that I'm referring to the 80286, whereas
you cite something ...

> From wikipedia:
> 
> "Rather than concatenating the segment register with the address
> register, as in most processors whose address space exceeded their
> register size, the 8086 shifted the 16-bit segment only 4 bits left

... about the 8086.  To make it very obvious, even to you: 86 vs 286.

As you have so huge experiences with such old processors, I'm sure
you can guess what I meant with "real segmentation" aka protected mode now. 
In case you still can't and because we seem to start using wikipedia to back
up claims: http://en.wikipedia.org/wiki/X86_memory_segmentation .

Now, implement a routine that subtracts two pointer for this memory model.
You'll see that it requires bit-magic on the segment selector,
lookup in the GDT or LDT and finally some 24bit arithmetic to produce
the result.  The arithmetic is of course trivial, the lookup is expensive.
Doing it for every pointer subtract was what I called prohibitive expensive
for a normal pointer subtraction.

That, together with the fact that all
segments are max 2^16 in size, and that it's impossible to map back all
24bit numbers into segmented addresses without generally adding new
entries into the GDT/LDT made it useless to have pointer differences
any larger than 16 bit, not impossible but useless in real compilers.
Therefore the result of such a subtraction isn't always representable.

> > [ ] Yes
> > [x] No
> 
> Thanks. The comunity will be alerted to this. I'll get back to you when
> your name is in some famous place associated with this claim.

That's very good.  Though I'm a bit confused because you only wanted to
post my name everywhere if I got the answer wrong.  Now, it's very obvious
that my answer is the only correct one.  Well, nevertheless I'm looking
forward to become famous.  Thanks for your help in that, though I fear
somebody else will become even more famous than me.

(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 no linear
> > > relationship between effective address and segment+offset"
> So, I think it's pretty clear that I'm referring to the 80286, whereas
> you cite something ...


Oh really? Because you so cleverly used the word "real" to lead me to believe you were talking about real mode 286? How clever of you, you were talking about protected mode after all.

Ok, after interpreting your incorrect wording I can give you that: 286 protected mode was a pain. You just dropped your error rate to less than 100%, kudos!! (should adjust your phrasing though, if you want to be correctly inrepreted)


> > From wikipedia:
> > 
> > "Rather than concatenating the segment register with the address
> > register, as in most processors whose address space exceeded their
> > register size, the 8086 shifted the 16-bit segment only 4 bits left
> ... about the 8086.  To make it very obvious, even to you: 86 vs 286.
> As you have so huge experiences with such old processors, I'm sure
> you can guess what I meant with "real segmentation" aka protected mode now. 



There is no thing as "real segmentation", you must have made it up. The Linux community seems to talk a little about it... but I never saw Intel say or write anything about it when I was studying the 286. Linux guys use that expression, is that why you thought it was standard?

Wrong.

What Intel defined was "real mode" and "protected mode". So you see what you do when you don't use your words correctly and call it "real segmentation"? Of course it would look like "segmentation in real mode". Your bad. Unless you can backup "real segmentation" with some official doccument from Intel, can you?



> In case you still can't and because we seem to start using wikipedia to back
> up claims: http://en.wikipedia.org/wiki/X86_memory_segmentation .


No mention of "real segmentation". Is this what you wanted to show me?


> Now, implement a routine that subtracts two pointer for this memory model.
> You'll see that it requires bit-magic on the segment selector,
> lookup in the GDT or LDT and finally some 24bit arithmetic to produce
> the result.


Yup, too much work. Better leave it alone and return some random pointer subtraction number. Better yet: don't compile such code. And never again guarantee to anyone anything about pointer subtraction unless it fits inside C99 box.

I had one class on 286 which made us implement processes on a minimal protected mode OS for the 286. I can tell you it isn't that hard to read the LDT or GDT, and it didn't have any prohibitive performance penalty, contrary to what you claim. Maybe you are confusing yourself between reading from and writing to the GDT/LDT? Or maybe you can backup your claim that reading from GDT/LDT is prohibitive?


>  The arithmetic is of course trivial, the lookup is expensive.


Could you please back it up? That's contrary to my experience, you see, and since it lacks logic since the processor reads to those tables were designed to be fast to make it run fast... so I think you should back that up, otherwise it just looks like you are making it up (not to me though, I know it wasn't prohibitive).


> Doing it for every pointer subtract was what I called prohibitive expensive
> for a normal pointer subtraction.


Yes, you are wrong to call it prohibitive. You just want to imagine it to be prohibitive so that you can stick to your claim that pointer subtraction result is not guaranteed by GCC *EVER* because of the 286. What a boring unsubstantiated argument. Without backing up such illogical claims its all just jiberish.

So go ahead and find a techncal paper or report that shows that reading the LDT or GDT causes a significant performance penalty. Let's set a threshold: 50 instructions? So, ok: if you can find such a document that says that accessing those tables always costs 50 instructions or more then I'll grant you that the compiler should have an option to disable correct pointer subtraction. I will still not grant you an incorrect pointer subtraction by default, but I will <insert apology here> in that my experience with 286 was unexplainably better than yours. If you can't find such a document then <insert apology here for making unsubstiated claims> and forget about it (apology accepted).


> That, together with the fact that all
> segments are max 2^16 in size, and that it's impossible to map back all
> 24bit numbers into segmented addresses without generally adding new
> entries into the GDT/LDT made it useless to have pointer differences
> any larger than 16 bit, not impossible but useless in real compilers.
> Therefore the result of such a subtraction isn't always representable.

In the copilers I used back then the far pointer was 32-bit, just like it was 32-bit on the seg16:ofs16 pair. So the compilers we used didn't need to check on any GDT/LDT as they approached a flat 24-bit memory model and could do all arithmetic with the 32 bits alone.

Didn't your compiler do that?? What did it do with a far pointer? Keep only the 16 bits? Really???? So you could only access 64k then? Crappy compiler. Your point has been proven for your crappy compiler, congratulations.

I don't know how the compilers I used converted near to far and back, but we didn't really used to do that. However that is not the point because I never asked you about pointer subtraction with mixed qualifiers.

In fact, you are just digging a deeper and deeper hole for yourself, as I placed 2 equivalent pointers:

char* p1=...
char* p2=...

... and then asked about their subtraction. None of them is far, because (as you should know) the default was near in just about every compiler (naturally!!).

So you made up segmentation as an excuse, and you are drifting away form the original issue. That issue is that, on any platform, pointers defined like this must *ALYWAYS* return the correct difference.

And for that original issue (as for many others we started making up as we went along) you are just wrong. Had I written "far char*"... but I'm not stupid. I'm just a mean son of <some animal>, right?

:-)

(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 trust that p2-p1 will always return a predictable and well
> > defined integer value of 0x1000 on any platform with 16-bit or more that GCC
> > currently supports or that will come to support in the future?
> [ ] Yes
> [x] No


There you go, you are now famous.

http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism

The comunity has been warned about GCC. It was a good day's work after all.

Congratulations.  Are you done now?

What else are you hoping to achieve?
Is this a cry for attention?

(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 that computing pointer subtraction is not guaranteed to be accurate on GCC.

My personal gains will be (possibly):

1) Maybe the community can force GCC to start making such guarantees. That would help all of us. The example I posted there is real, I'm not making anything up!

2) Showing all of you that a compiler should be more than just C99. A good compiler need to be more than C99. And an excelent compiler must be more than just C99. All of you confine your answers to C99 forgetting that a compiler will be used in many real world situation, for example in memory mapped devices.

3) Showing Michael that he says a lot of crap. Show him that he just shot himself in the foot for not thinking before speaking. Maybe get him to think before making claims? Even with all my warnings he didn't think of people that compile for memory mapped devices? He should think before he says something, he is not just some random guy like me, he is a representative of the GCC project and his answers (crap included) are GCC-binding.

I confess I get some satisfaction out of that 3rd item. But I would do it even if I had the first 2. The community at large thinks more like I do, and expect the pointer subtraction to always return accurate results. I'm just warning them. I'm not lying. I'm not distorting anything. If it helps someone then good, otherwise it can«t harm anyone, right?

That's it, really. As for the bugs I reported I have no further hope.

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 to the world and save the planet. Just imagine, how the link to this enhanced compiler would be a great addition to your Wikipedia entry!

You can even call this custom compiler whatever you like, except gcc.

You will rewrite the history!

(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 to the world and save the planet. Just imagine, how the link to
> this enhanced compiler would be a great addition to your Wikipedia entry!
> You can even call this custom compiler whatever you like, except gcc.
> You will rewrite the history!

It sounds like a good deal. Really, I'm not being sarcastic in any way. I would like to have 5000 to invest on GCC.

Maybe you all got me wrong: the reason I wrote the 2 bug reports is because I do think GCC is a *very important project for the community*. I'm being honest. If GCC were not important I would not have gone to any trouble at all, yet alone spend several hours writing 2 or 3 complete reports (with files and snapshots) and many messages. Maybe it is time for you to understand what I really am all about. I say stuff about GCC, I've called "lowest common denominator" (and I mean it), but I still think it to be among the top 5 most important compiler projects in the world (including Microsoft's and Intel's and a bunch of comercial compilers). It could be top 1, if it weren't for being so confined to C99 and not *want* to go beyond it.

And I would like to have 5K to put on GCC. As I said I know I can't demand anything, after all the thing is being offered to me! Even more than that: it is being offered to me without me having ever contributed with a bit. So, as I said before, I'm not demanding anything (nor could I).

I was just hoping that you would see the importance of "my feature" (although I still call it a bug and not a feature, and if you want I can give you examples of why it is important to be able to initialize classes as function parameters). You didn't see it? Or you saw it but you don't agree that it is important? I'll insist, I'll bring new angles to the discussion. Still no? I'll insist some more, maybe get some other examples. Nothing still? Whatever, I'll shut up and go away, no problem. The reason I'm still here is (to a great extent) because of Michael... that guy just cracks me up. It is possibly the person that I've ever known that has such a high "error rate" (it was up to 100% for a while there!). But this conversation has stopped being about my bug reports a long long long long time ago. I'm on vacation, so I have had more time on my hands than I'm used to, and Half Life 2 bores me a little if I play it for too long! :-) ... so I keep comming back. As I said before I will seek help. Just one more, this is the last one!!! Promise!! I'll buy a new game and leave you all alone soon! :-)

I posted the criticism on Wikipedia not to hurt anyone in particular. But I do criticize GCC for not being able to guarantee correct pointer arithmetic. And me, as a citizen of this world, have the right to make my criticism and post it where everybody can see and judge for themselves. And, being an important criticism, I should back it up. So I did, and posted 2 references.

I was very careful not to write anything that might be incorrect or misleading. I quoted our conversation almost exactly. And even with the different words I made sure the content is exactly the same as in my conversation with Michael. I didn't lie. I didn't distort. I didn't exagerate. I didn't take it out of context. I said it like it is, no more, no less.

So here is the deal to you:

If you all agree with Michael then my Wikipedia post is correct and has a reason to exist, and people like me will want to be alerted to what it says. Programmers don't go around reading C99, generally speaking they just try to write good code. That's it. I would guess 90%+ of programmers don't go out checking if their line of code is C99 conformant or not. However, I believe their code can be more than 99.9% C99 conformant, so very little people have any problems.

I'm one such programmer, I hadn't read C99 before talking to you but 99.9% of what I do falls completely within the things defined in C99. But there is a fraction of what I do that does not fall there, and I still have to do it. And like me there are many others, who have a fraction of their work fall outside C99 (without knowing). And the code still has to work. Always. Guaranteed. And we trust the compiler to give us the "expected" result. Always. Guaranteed. If I am wrong in trusting it then I want to be alerted. That's all I did in the Wikipedia post: alert people that do code for memory mapped devices and similar (like I often do).

So if you think Michael is correct then he is, in fact, a hero. He is the one guy, on the face of this planet that I know of, that had the balls to come out and say "beware of pointer subtraction when using GCC!!". No sarcasm here, I trully believe this.

If he is, in fact, right then I will personally thank him because up to this point I trusted pointer subtraction implicitly for *ANY* compiler in the world. My conversation with him shows that I've been trusting that since the 80's, from the time of the 8086 or 80286. And I've been successful always, so I kept on believing all these decades.

So, at the same time I criticize GCC's "unreliable pointer subtraction" I could write in Wikipedia that Michael is the guy who provided this information to the world. If he is right then I already did that and his name is there for the credits. And I already know he truly believes he is right, so I must not have hurt his feelings in any way.

I wrote the criticism on Wikipedia because I really believe that if Michael is right then GCC is a very big risk for memory mapped devices (or cases that need similar constructs). And I do believe it is unacceptable to any developper that code that is working today may break tomorrow for some unexpected event (unexpected on the programmers part, since memory mapped devices are outside C99's definitions). I kid you not, I've seen problems cause by compilers too many times.

As I told you before I had 3 reasons to post my message there: any of the first 2 would have been enough to go to Wikipedia, the 2 together even more, the 3rd is just an added bonus, by itself it wouldn't justify posting anything anywhere. And Michael said a lot of crap, but only the pointer subtraction was important enough to affect the programmer's assumptions and merit public display. The rest I just ignored.

As we both know, code built with GCC (or any other compiler) always produces correct results. And we know the results will forever be correct, because one would have to write specific code in the compiler to mess up the arithmetic at those specific instances not defined by C99 (something like "if (p1 or p2 not in c99 known space) then mess up p2-p1"). But according to Michael we cannot trust that, officially, because C99 does not define it, and I criticize that (and a large part of the comunity will too). Hence my hope that GCC will benefit from the post, in the long run.

Now if Michael is wrong then that is a completely diferent matter. Personally I believe he is wrong, and I think he is an idiot. He let his personal pride and inability to take a criticism and shut up reach the point where GCC got hurt. He should have seen I'm not stupid. He should have realized I'm not your average run-of-the-mill pain in the ass. He should have suspected he was going to get hurt if he were not careful. He should have realized he was officially speaking on behalf of the GCC project and should have taken a step back. But, as I said, the guy just throws himself head on into walls.

I don't say this of the rest of you: you've given me your opinions, and I have respected them (at least I tried, but I didn't always succeeded as was pointed out to me about my "opening lines" for this bug report, and I already apologised for that). So, for the rest of you, I just say you are wrong for being so confined to C99, but I don't think you are idiots for that.

On top of that I don't know how busy you are, so even after realizing that you didn't read all my posts and reports thorougly I still cannot blame you for that. Seen that GCC has many comercial interests behind it I don't even know if you are getting paid by some company to put up with me or if you are doing it just for "the fun of it". So I must be understanding, and I tried to be. Furthermore, I recognize that I must be humble about it and I cannot make any demands about GCC, so I didn't. And if that is your opinion then tough luck for me. No sarcasm here either, I agree.

However, if Michael is wrong then he is, in fact, an idiot. I already think he is an idiot, but if he is wrong then everybody will know it. If this is the case Michael should recant. He should swallow up his pride and just come out and admit it. Not for me, but because this matter is much more serious than he thinks. A lot of people out there trust GCC implicitly, without having read C99.

If Michael recanted my temptation would be to leave the post in Wikipedia and add "However, Michael later recanted", just to to screw with him. That would teach him that once you say it its out there and there is no getting it back. Maybe teach him to think before saying unsubstantiated crap. Maybe the GCC bug tracking team would benefit if Michael could learn such a lesson.

However I'm not really a petty guy, and if Michael recanted then, in the spirit of Wikipedia, the whole post should be removed. And I would do this gladly, free of charge! :-) Why? If Michael is wrong then developers can, in fact, trust pointer arithmetic implicitly, so the criticism post in Wikipedia loses its reason for being (it would no longer be a reason to criticize GCC).

So, what is the bottom line: is Michael right?

Please, start a blog and write your views somewhere else. PLEASE.

You're rude, ignorant and annoying.

(In reply to comment #48)
> of why it is important to be able to initialize classes as function
> parameters

You clearly don't know what you're talking about. If you think the C++ language is incorrectly defined then take it up with the C++ Standard Committee, or your national standards body, not with GCC.  GCC implements the C++ standard. If there's a problem with the standard, change the standard, not GCC.

But the standard won't change in this respect. You cannot initialise a non-const reference with a temporary in C++, Microsoft's compiler is wrong to accept it, try Intel's compiler for confirmation if you don't believe me.

Andrew already told you to read about rvalue-references, which allow you to bind a reference to a temporary, but you're too busy arguing to accept that maybe, JUST MAYBE, someone knows something you don't.
So please, stop posting here and go away.  Publish your ideas where someone gives a damn.

Oh, and if you do get people to understand that pointer arithmetic is not always well-defined, that would be a good thing.  There are other people who share you're incorrect understanding of the C and C++ languages, so educating them is a good thing.  But you won't do that by posting here.

> There you go, you are now famous.
> http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism

Thank you, that's encouraging, I just hope the language of that article won't be changed too much to also mention everyone else who has a clue.  Because,
you see, I'm of course very excited about me being famous now and about being
the only one who knows the truth, but OTOH I fear there were some other
clever people that happen to agree with me, and I now see a real
danger of those replacing me in that wikipedia article.  Even worse would be
that the list of names would be too large to mention in wikipedia and that
the list would be replaced by some more unspecific phrases like "people who
actually understood the standard" or the like.

> The comunity has been warned about GCC.

Which community?  Rogerio-cdecl church followers?  In that case I'm happy,
because I'll expect less bug-reports from supporters of that specific
religion.  I'll continue to feel sorry for them (especially because I've
learned over the conversation that you might actually influence new
programmers, which is a terrible thing to do for you) but am not particularly
looking forward to seeing misguided and crippled attempts of creating
meagre imitations of stumbling pseudo bug-reports, especially because we
can have the best there is: Rilhas bugs!

If, OTOH, you mean a different community, like for instance that consisting of
people who actually write C source code, I don't see any warning about using
GCC for them.  If anything, it's more like an invitation to use GCC for
developing because it's more standard compliant than other compilers.

> It was a good day's work after all.

You mean writing down incoherent brain-dumps?  Uhm, well, if that's all your
day-work is about... more power to you!

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)
>You're rude, ignorant and annoying.

Yes I am. But a little bit less every day, thanks to (respectively) my mom, your clarifications about the standards, and my 12-step program.



(In reply to comment #51)
> > There you go, you are now famous.
> > http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism


Why did you remove the post? Do you think something there is not true? You said it, why is it not true? Are you recanting? Wikipedia is the place to post true statements, it if is the truth then it should be there. Don't tell me now that you are ashamed of what you said, are you?

Please: you and your friends keep of from removing a perfectly valid criticism that I backed up with your statements. You think you can just keep on removing, but I'll just keep on putting it back. Until I get bored and take it up to Wilkipedia. Why didn't you remove the other guy's criticism about GCC being buggy and producing crappy code? Is his criticism better than mine? Is it better substantiated than mine?


> Thank you, that's encouraging, I just hope the language of that article won't
> be changed too much to also mention everyone else who has a clue.


No, from the time I posted it first I changed it only once because I realised (based on it being undefined right now) that the code could break at any time, not just with future releases of GCC.


>  Because,
> you see, I'm of course very excited about me being famous now and about being
> the only one who knows the truth, but OTOH I fear there were some other
> clever people that happen to agree with me, and I now see a real
> danger of those replacing me in that wikipedia article.



I don't see where you are getting at. I don't want you to be the only one who knows the truth, I want everyone to know about it. Duhh!! Why else would I post it on Wikipedia?? I don't want GCC to keep any secret pitfalls from anyone, is that alright with you?




>  Even worse would be
> that the list of names would be too large to mention in wikipedia and that
> the list would be replaced by some more unspecific phrases like "people who
> actually understood the standard" or the like.


Ah, I see. You are afraid of someone removing your name from the post? I won't do that, I promise. And while the reference to your comment is there you will always have a place among the stars. So be sure to try your best to keep it there!!



> > The comunity has been warned about GCC.


Everybody who reads Wikipedia. Some of them are programmers.


> Which community?  Rogerio-cdecl church followers?


Possibly. In between our other rituals. My followers use their prayer time as they like, many of them use that time to seek enlightment. They can get it from wherever they like, including Wikipedia. Or C standards. Or bugzilla bug reports. Whatever.


>  In that case I'm happy,
> because I'll expect less bug-reports from supporters of that specific
> religion.

Sure, you already shut me up. And I thanked you, remember? (I still have the same opinion of you, but your "error rate" dropped a little more... still impressivly high, though). I confessed that I did learn from your post (not being sarcastic, I really did).



>  I'll continue to feel sorry for them (especially because I've
> learned over the conversation that you might actually influence new
> programmers, which is a terrible thing to do for you) but am not particularly
> looking forward to seeing misguided and crippled attempts of creating
> meagre imitations of stumbling pseudo bug-reports, especially because we
> can have the best there is: Rilhas bugs!

Yup. I now realize why my bug reports aren't really bug report. Just some side-effect of me not realizing the full impact of GCC just following standards.

It claims is cdecl conformant, but even without optimizations it doesn't place parameters on the stack as cdecl states. My bad, GCC does not guarantee cdecl anywhere, you are right. So I'll just shut up with that.

And getting the address of parameters? You are right, not defined in the standards. You are right too. So I'll just shut up with that too.

So, the 2 bug reports are, thus, squashed as invalid. (not being sarcastic either).

As for Rilhas' bugs? None, as long as I steer clear of GCC. And my code works? Yes. And am I good at what I do? Yes? How do I know? My mom tells me so all the time (and besides I continuously get paid very well, which is my second strongest indicator that I do a good job). Am I afraid of doing non-standard things? No, standards have to keep up with the real world and with "special pusher compilers", like MSC. If one day some standard realizes that what MSC does is clever and adopts it then GCC will eventually follow. If not then I'll just keep on using MSC. What if I can't? I'll cross that bridge when I come to it, meanwhile me and my followers make code faster and more confortably year after year after year.



> If, OTOH, you mean a different community, like for instance that consisting of
> people who actually write C source code, I don't see any warning about using
> GCC for them.


You don't see it because you removed it. Or your frieds. Or your mom. Not really important. It was removed by someone who didn't present a any reason why it is not a valid criticism. You say that other criticism there? People who want to refute it add stuff like "citation needed" or "needs references".

I've put it back again. You can take it down again, but you will just make me ask Wikipedia referees to lock it and so you will get even more exposure. They'll check it and see I'm not doing anything wrong.

The fact that you (or your frieds) keep removing it just proves to me that you are somewhat ashamed of what you claimed. If not then just let it be.

BTW: don't bother sneaking late at night to remove it because I have a bot warning me the second the post gets removed (or modified). So you, your friends, your mom, nor your dog will ever win this one unless you recant.


>  If anything, it's more like an invitation to use GCC for
> developing because it's more standard compliant than other compilers.


That claim should be backed up so that everyone knows if your "others" include MSC or Intel. Please demonstrate why GCC is more standards compliant than MSC or Intel's, or otherwise your sentence is just shallow. This is the kind of stuff that comes back to bite you in the ass because if you can't demonstrate it you may end up on Wikipedia with something like "Michael Matz, from the GCC bug tracking team, failed to demonstrate any way in which GCC is more standards compliant than MSC or Intel". Like the mean-ignorant-rude bastard that I am I would do it! Shouldn't you be more careful about what you claim at this point? Do you have some impairment that I don't know about? Don't make claims you are unable to substantiate.


> > It was a good day's work after all.
> You mean writing down incoherent brain-dumps?  Uhm, well, if that's all your
> day-work is about... more power to you!

Yeah... sure... or, in my words, I learned a lot. You didn't.

I learned GCC cannot be trusted in any situation not covered by the standards. I didn't know that. I was very very ignorant and now I'm just ignorant. Good, that's not bad for a day's work.

You saw that GCC conforming to "just standards" leaves out a very large number of real world applications. Isn't the embedded and experimental platforms one of the most important targets for GCC? Shouldn't GCC try to make more guarantees than just standard then? GCC is just average. GCC is just standard. Like a standard car, or a standard dishwasher. It does no better than average. It is not special.

Others strive to be special. A special car, a special dishwasher, a special compiler. Those do what is standard and more, and that makes them great. You didn't learn that. Too bad for you.

You seem to be unable to understand this. My English is surelly very bad, I'm sorry, it is not my native language. Let me try it another way.

standards=average
standards+other_stuff=special

GCC=standards=average
MSC=standards+old_school_stuff+new_bleeding_edge_stuff=special

memory_mapped=standard+old_school_stuff
memory_mapped+GCC=not_guaranteed=unreliable
memory_mapped+MSC=reliable

GCC<reliable[memory_mapped]

programmers_for_memory_mapped_need>=reliable
programmers_for_memory_mapped_need+GCC=maybe_break_someday

GCC could be better in the future if it added something. I get it, you don't want to go outside any standard. I get it. For a long time it frustrated me that you didn't want to, now I have made my peace with it. Really.

You still don't get it? Who cares.


(In reply to comment #49)

This code:

res=function(class(initializer))

Does not compile in GCC. Why? Who cares!! You have shown me that it has something to do with not being defined in the standard or whatever. Don't miss the point, I don't care why. I didn't ask you to explain to me why GCC can't. I didn't ask you what it would take for GCC to be able to do it. I didn't ask you to change the standards. And I certainly didn't ask GCC not to go beyond standards! I would burn in hell surely (well, even more so).

It is simple, try to understand: GCC can't, MSC can. GCC is average, MSC is above average. I have to manually do an equivalency for GCC to compile:

{
class random_name(initializer);
res=function(random_name)
}

It is stupid that I have to do this manually. Stupid of the standards? Probably, but I don't know why it is not there, so I won't say anything about it. Stupid of GCC? Well, possibly. Microsoft probably also knows about the standards and solved it, why not GCC? Can it be done with "move constructors"? Who cares! As far as I'm concerned it could have been done with the preprocessor!!

You just keep missing the point!!!!!!!

I just informed you: MSC can, GCC can't. Period. Your little brains couldn't take it. It was too much for you. You just made a really big effor to explain to my why it can't and didn't realize I don't care and that was not the point!!

Was Microsoft wrong? No, us in the real world love it. In fact, this code:

class Color;
class Vector;

virtual func(Color c=Color(WHITE), Vector v=Vector(VECTOR_Z));

Has no workaround for in GCC. Why? Because GCC can't initialize parameters that are classes. MSC can. So this code (which I needed to do, no real practical alternative), cannot be compiled in GCC. Why? Because GCC doesn't go beyond standards. Period.

What about me overloading the function in GCC? That would solve it!! No, wrong. It is virtual, I don't know who derives the class and overrides the function. So with GCC I would be stuck, and the code would not have been produced in time for my clients to pay me.

Was Microsoft right to make such a special compiler and let me do things not in the standards? Yes. Is what I'm doing called C++? I think so, but I don't really care, as long as it works *RELIABLY* and *GUARANTEED* (MSC guarantees this). Should the standards be updated? Probably. Will I do it? No. Do I have a problem? No, I'll just avoid GCC.

So don't keep missing the point. I am *INFORMING YOU* that MSC can and GCC can't. And I'm also *INFORMING YOU* that I don't care why GCC can't. It just can't. You don't care about this information? Drop it.

So keep throwing standards at me and call me ignorant and see if I care.

(In reply to comment #52)
> (In reply to comment #51)
> > > There you go, you are now famous.
> > > http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism
> 
> 
> Why did you remove the post? Do you think something there is not true? You said
> it, why is it not true? Are you recanting? Wikipedia is the place to post true
> statements, it if is the truth then it should be there. Don't tell me now that
> you are ashamed of what you said, are you?

Look at the page history, it was removed by someone else, probably because your comment is badly written and not suitable for the Wikipedia page.

As with most of your comments, they are unfounded and easily refuted by checking facts, but you're so sure you know them that you don't need to check.

As you've said before, learn to read.

> Please: you and your friends keep of from removing a perfectly valid criticism
> that I backed up with your statements. You think you can just keep on removing,
> but I'll just keep on putting it back. Until I get bored and take it up to
> Wilkipedia. Why didn't you remove the other guy's criticism about GCC being
> buggy and producing crappy code? Is his criticism better than mine? Is it
> better substantiated than mine?

Wikipedia editors are our friends now? Are you paranoid?
 
> I don't see where you are getting at. I don't want you to be the only one who
> knows the truth, I want everyone to know about it. Duhh!! Why else would I post
> it on Wikipedia?? I don't want GCC to keep any secret pitfalls from anyone, is
> that alright with you?

Noone wants it to be a secret, everyone in the GCC project would prefer if no users shared your incorrect beliefs.
 
> It claims is cdecl conformant, but even without optimizations it doesn't place
> parameters on the stack as cdecl states. My bad, GCC does not guarantee cdecl
> anywhere, you are right. So I'll just shut up with that.

Check your favourite reference - the Wikipedia entry on cdecl says GCC is the de facto standard for caling conventions on Linux - so by definition what GCC does is correct.  It must be true, Wikipedia says so.
 


> Was Microsoft wrong? No, us in the real world love it. In fact, this code:
> 
> class Color;
> class Vector;
> 
> virtual func(Color c=Color(WHITE), Vector v=Vector(VECTOR_Z));
> 
> Has no workaround for in GCC. Why? Because GCC can't initialize parameters that
> are classes. MSC can. So this code (which I needed to do, no real practical
> alternative), cannot be compiled in GCC. Why? Because GCC doesn't go beyond
> standards. Period.

What are you talking about?  You were originally talking about initializing non-const references with temporaries.  The code above would work fine, if you'd defined Color and Vector.

class Color { public: Color(int); };
class Vector { public: Vector(int); };

const int WHITE = 0;
const int VECTOR_Z = 0;

class Idiot {
virtual void func(Color c = Color(WHITE), Vector v = Vector(VECTOR_Z));
};

GCC compiles that fine, try it.
GCC compiles that because it's valid C++.
What is your point?

Keep this up, future employers will love to see you making an idiot of yourself so publicly.

(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. Do you like it?
Better get used to it, I'm a mean sonofagun and I'll keep showing you why you're wrong.

You're an idiot.

(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 for the Wikipedia page.

I thought that was your mom, sorry. We are alright then. When the guy removes it again I'll tell him to ask you if it is true. If you don't recant he will know I'm telling the truth.


> As with most of your comments, they are unfounded and easily refuted by
> checking facts, but you're so sure you know them that you don't need to check.
> As you've said before, learn to read.


Right, that must be it. As if I didn't backed it up with your own comment #35. Boy, it will sure be easy to prove my post to be unfounded!!!



> Noone wants it to be a secret, everyone in the GCC project would prefer if no
> users shared your incorrect beliefs.



So do I. I don't want anyone sharing my incorrect beliefs. Did we just agree on something here? So I'll tell the guy to talk to ask you.



> Check your favourite reference - the Wikipedia entry on cdecl says GCC is the
> de facto standard for caling conventions on Linux - so by definition what GCC
> does is correct.  It must be true, Wikipedia says so.


... unless it was your post! You tend to miss more than you hit. But yeah, you've shut me up on that too. I just wrote that in my previous post.


> What are you talking about?  You were originally talking about initializing
> non-const references with temporaries.

Yes, that is right. GCC gave me the same error in both cases (aren't default parameters initialized with classes the same as parameters initialized with classes?). Probably my bad.

>  The code above would work fine, if
> you'd defined Color and Vector.
> class Color { public: Color(int); };
> class Vector { public: Vector(int); };
> const int WHITE = 0;
> const int VECTOR_Z = 0;
> class Idiot {
> virtual void func(Color c = Color(WHITE), Vector v = Vector(VECTOR_Z));
> };
> GCC compiles that fine, try it.

Yeah, you are right, your class does. But mine don't, the diference is that mine are a bit more complex and derive a lot... but you were right, yours does compile. And I was right, my code with GCC would have given me more trouble to deliver to the client. But you are right, I posted an Idiot class. (see how easy it is to admit when we are wrong? .. if you tried it you would quickly gain a lot of practice! ... anyway, good job in reducing your error rate, it is now close to a normal person!)


> GCC compiles that because it's valid C++.
> What is your point?
> Keep this up, future employers will love to see you making an idiot of yourself
> so publicly.


No, the worse is being wrong and don't admit it. When we admit we learn, so I've been learning quite a lot with you guys. You didn't admit anything, so in your mind LDT read accesses a still prohibitive, and crap like that. Or did you think I would forget all the crap that you said that I shot down and you didn't admit?? Your future employers (if any!) will see that your ability to learn simple stuff is impaired.

(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. Do you like it?
> Better get used to it, I'm a mean sonofagun and I'll keep showing you why
> you're wrong.
> You're an idiot.

Yeah, I've seen you show me I said crap that I didn't study well enough before saying it. I learned, it will never be repeated.

All the rap you said that I shot down didn't make you learn anything.

We are both idiots, but I'm a little bit less every day. I've left you behind a long time ago.

(In reply to comment #55)
> (In reply to comment #53)
> > Look at the page history, it was removed by someone else, probably because your
> > comment is badly written and not suitable for the Wikipedia page.
> 
> I thought that was your mom, sorry.

Good way to make a convincing argument.  You've tried to turn this into a "your mom" argument in three replies now, but noone seems to be rising to the bait. 

> No, the worse is being wrong and don't admit it. When we admit we learn, so
> I've been learning quite a lot with you guys. You didn't admit anything, so in
> your mind LDT read accesses a still prohibitive, and crap like that. Or did you
> think I would forget all the crap that you said that I shot down and you didn't
> admit?? Your future employers (if any!) will see that your ability to learn
> simple stuff is impaired.

Are you confusing me with Michael?  I've not said anything about LDT.

What am I supposed to admit?  That GCC compiles valid C++ code?
That I've wasted time replying to you?  That's true, but it's my weekend and I'm waiting for a GCC testsuite run to finish so I have time.

You keep accusing GCC of not compiling useful C++ code, but haven't shown a valid example yet.  I am happy to learn but I don't see anything worth learning from you, your opinions or your "debating" style. Even your trolling skills are poor, and you started so well.

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 this into a "your
> mom" argument in three replies now, but noone seems to be rising to the bait. 

Not an argument. I said I was sorry to think it was you or one of your friends (is Chris your friend?). Anyway, I understand why you got confused and missed my apology, I inserted the mom joke. My bad, it was not funny at all, and you thought it was an argument. My bad.



> Are you confusing me with Michael?  I've not said anything about LDT.

Yes I am. I'm sorry for that, I really am. I got mixed up. We were discussing the post and I didn't check the sender. There are just too many of you guys. I'm sorry, this comment wasn't meant for you (I must be getting tired).



> What am I supposed to admit?  That GCC compiles valid C++ code?

You don't have to admit anything really. But in your comment #34 to bug #45249 you missed the point entirely and just spewed out standards. You missed the point really, as I was saying "GCC can't", and it really can't. Spewing out standards just to explain "GCC can't because <insert standards here>" was not really useful for that discussion. Does not make an idiot out of you though.

Then you claimed <What a charming idea, that a compiler could become perfect by doing "what I said it should">. And that is very close to making an idiot out of you, because you deflected without getting the background for the conversation straight. I had to show you (again) that <you failed to see that "what I say" is what "C99+cdecl" say>.

These all don't make an idiot out of you yet. Adding them all together was borderline-idiot, but still safe.

Then, for this bug, your comment #45 missed the point. You didn't understand why I posted it on Wikipedia, although it is well explained there. But ok, I'll grant you that that also does not make an idiot out of you.

... then, from comment #53 on we really looked to me like Michael, so I lost it. Here I go, back to being more of an idiot, and there you go not an idiot yet.



> That I've wasted time replying to you?  That's true, but it's my weekend and
> I'm waiting for a GCC testsuite run to finish so I have time.
> You keep accusing GCC of not compiling useful C++ code, but haven't shown a
> valid example yet.

Yes I have. It is there on Wikipedia. The code compiled is not valid (in a functional sense) because the programmer cannot trust the pointer difference. Maybe at this point you get confused because you didn't type "valid [according to standards] example", but you didn't type it. So valid is open for discussion. And I say that is valid if it returns 0x4000-0x3000=0x1000.

So there you go, now you're an idiot like Michael (well, still less, your error rate is much lower and of much less significance). You are an idiot because you don't know what "valid" is to everyone, you just think you do because you know of some standard that says what is "valid" in a given context. I do assembly inside my C code with MSC, is that not "valid" because it is not defined in any C standard? Nope. It is "valid", no matter how much you kick and scream.

With the same train of thought I could talk about initializing classes as parameters to functions as in comment #25 of bug #45249 (as another example I posted and that you didn't see), because, again, you didn't explain what the "valid" word in your text was supposed to mean. I know you mean standards, but there is more to it. But this one does not make an idiot out of you because "valid" is much harder to define here. So I'm am not in a position to spot the level of idiocy in your comment (I'll just assume it is none). So I say "valid" (outside in the real world) and you say "invalid" (based on C standards), but none of us are idiots for it.

>  I am happy to learn but I don't see anything worth learning
> from you, your opinions or your "debating" style. Even your trolling skills are
> poor, and you started so well.

That's my point. You keep proving my point. You don't feel the need to learn anything from me because you are all cosy inside your standards box and look down on the other kids playing outside in the real world. You wear all your silk-based standards shirts and mock the dumb kids in the playground that use silk+cotton immitations. You call them idiots even after they've shown you that when you are outside silk doesn't cover all the needs. You don't even realize that I'm right that GCC thus alienates memory mapped device programmers, thus making it inferior to many others. You're stuck in idiot-land.

I still don't know what a troll is. English is not my native language. Checking the web it seems like a troll is someone whose primary purpose when posting comments is to provoke disruption. I don't feel like that, I posted what I thought to be actual bugs in GCC. And I backed down my claims when I finally understood that GCC does go anywhere where standards don't tell it to go. I backed down because you've shown me it is not a bug. I'll grant I've put up a fight, but for me it was a fair fight. The Wikipedia post shows that, it is me admiting that I got GCC all wrong from the start. At this point I'm just arguing like you are, I don't think I'm any more of a troll than you. As for my skills as a troll being crap: that seems only natural, I don't have any intent to disrupt anything.

(In reply to comment #58)
> 
> (is Chris your friend?)

Of course not.  I have no idea who he is.

> > Are you confusing me with Michael?  I've not said anything about LDT.
> 
> Yes I am. I'm sorry for that, I really am. I got mixed up. We were discussing
> the post and I didn't check the sender. There are just too many of you guys.
> I'm sorry, this comment wasn't meant for you (I must be getting tired).

See, you talk crap?  (I'm responding like that because that's your manner of response, you attack and you insult and you aren't even paying attention to what you're replying to.)

> > What am I supposed to admit?  That GCC compiles valid C++ code?
> 
> You don't have to admit anything really. But in your comment #34 to bug #45249
> you missed the point entirely and just spewed out standards. You missed the
> point really, as I was saying "GCC can't", and it really can't. Spewing out
> standards just to explain "GCC can't because <insert standards here>" was not
> really useful for that discussion. Does not make an idiot out of you though.

GCC *could* compile invalid code, if we wanted it to, but it doesn't. That's by design, not due to accident or inability to make it work.
Several other C++ compilers don't compile it either.

The reason is because they aim to follow the relevant standards. And so that's why I referenced the standard. 

> Then you claimed <What a charming idea, that a compiler could become perfect by
> doing "what I said it should">. And that is very close to making an idiot out
> of you, because you deflected without getting the background for the
> conversation straight. I had to show you (again) that <you failed to see that
> "what I say" is what "C99+cdecl" say>.

Yes, that was sarcasm, in the (apparently wrong) hope that you'd get a hint and go away.
 
> > You keep accusing GCC of not compiling useful C++ code, but haven't shown a
> > valid example yet.
> 
> Yes I have. It is there on Wikipedia. The code compiled is not valid (in a
> functional sense) because the programmer cannot trust the pointer difference.
> Maybe at this point you get confused because you didn't type "valid [according
> to standards] example", but you didn't type it. So valid is open for
> discussion. And I say that is valid if it returns 0x4000-0x3000=0x1000.

The ISO C and C++ standards say what's valid in this context, not you.
 
> So there you go, now you're an idiot like Michael (well, still less, your error
> rate is much lower and of much less significance). You are an idiot because you
> don't know what "valid" is to everyone, you just think you do because you know
> of some standard that says what is "valid" in a given context. I do assembly
> inside my C code with MSC, is that not "valid" because it is not defined in any
> C standard? Nope. It is "valid", no matter how much you kick and scream.

No, in the context of a compiler which tries to conform to the ISO standard, the ISO standard is the definition of what's valid.

> With the same train of thought I could talk about initializing classes as
> parameters to functions as in comment #25 of bug #45249 (as another example I
> posted and that you didn't see), because, again, you didn't explain what the
> "valid" word in your text was supposed to mean. I know you mean standards, but
> there is more to it. But this one does not make an idiot out of you because
> "valid" is much harder to define here. So I'm am not in a position to spot the
> level of idiocy in your comment (I'll just assume it is none). So I say "valid"
> (outside in the real world) and you say "invalid" (based on C standards), but
> none of us are idiots for it.

You are welcome to use any definition of valid in your personal conversations, but in the context of a compiler which aims to conform to the ISO standards you don't get to decide what the definition of valid is.  And this bugzilla is, most certainly, in the context of GCC.

If you want to discuss other uses of "valid" or non-standard code, do it somewhere else, such as the comp.lang.c newsgroup.

G++ doesn't compile that code because the code is invalid, and binding non-const references to rvalues is unsafe, and C++ experts have decided that a conforming compiler should not allow it.  One reason for that is the following:

class X { int i; }

X& f(X& x) { return x; }

int main()
{
    X& x1 = f( X() );
    return x.i;
}

This code is unsafe because it accesses X::i after it has been freed.
The standard says it's not allowed, and G++ implements that.  You are free to say it should be different, but noone will agree with you.

(In reply to comment #59)

> See, you talk crap?  (I'm responding like that because that's your manner of
> response, you attack and you insult and you aren't even paying attention to
> what you're replying to.)

Its not crap, it was just not for you. And I apologised, unlike you *EVER* did in all cases you were wrong or missed the point.

No problem in you talking in that manner, you already warned me that would were capable of being rude. You're not even close to that by my standards, so no need to explain yourself.

What you don't understand is that I get e-mails from you that, depending on the sequence, seem like a conversation between 2 people (the contents is often directly related). But there are many of you, and you got me confused. I still don't know if you all read all the messages, or you read only part, but you seem to be somewhat synchronized... so maybe you are splitting the messages? Don't know, don't care, but it took me a while to realize that the replies didn't all come from the same guy. I don't think it makes an idiot out of me, it just makes you ignorant of how things feel like from this side. Even for this message I just started a reply without confirming if it came from someone other than you (now I've checked!!). And, as you said, I'm not that good of a troll, so my technique is very poor. It doesn't make me an idiot, just a bad troll.


> GCC *could* compile invalid code, if we wanted it to, but it doesn't. That's by
> design, not due to accident or inability to make it work.


There you go again. The "invalid" is not a well defined global concept. Just because you live inside standards don't think there is nothing else out there. I now know that GCC is all about standards, so I know of what context you are talking about. But my code isn't invalid, get that through your head! It's not just 100% according to your standards, but it is valid code (even when it mixes assembly or addresses of function parameters). Don't be so limited. That's one definition of an idiot! At least you could have written "invalid according to C++ standard X" or something like that, but you still don't think you need to because you believe that either it is "valid according to C++ standard X" or else it is "invalid". That is just plain dumb and you've made that mistake so many times it begining to look somewhat autistic.


> Several other C++ compilers don't compile it either.
> The reason is because they aim to follow the relevant standards. And so that's
> why I referenced the standard. 


Yes I know that. And after understanding that GCC would not want to go beyond I backed off and posted the Wikipedia warning to others. As you said, many share my misguided beliefs. Old beliefs. I'm now enlightend.



> Yes, that was sarcasm, in the (apparently wrong) hope that you'd get a hint  > and go away.


Sure, but it was "invalid sarcasm". What is "invalid sarcasm" you ask? Sorry I didn't define it: it is sarcasm where you distort what the other guy said to make it look like he said something diferent and stupid. That is what you do when you want to show off that the other guy is wrong but don't have any substance for it. It makes you look bad because people can see that the other guy didn't say or mean that, and they realize you had no substance. That is the strategy of idiots, non-idiots know it makes them look bad and don't touch the stuff.

BTW: you are not doing a good job if you are really trying to make me go away.


> No, in the context of a compiler which tries to conform to the ISO standard,
> the ISO standard is the definition of what's valid.

And in the context of a guy in the real world that uses C to program memory mapped devices the definition of valid is that pointer arithmetic must be always defined and correct. Can't you really grasp the concept that there is a world out there and that you don't get to decide that C code is only valid if it conforms to some standard?

There was C before the standard, people who knew C before the standard are the ones who know real and valid C. You just know standard C, which is a subset. So you don't get to say what is valid C to the rest of the world, you are just too small in comparison.

Me and many did study C in the university, when there was no real modern standard, and no comitee came knocking on our doors to take away our diplomas and tell us we should learn C all over again or else our coding would be invalid. So we do know C, not yours, but I do know C.

The comitees are smart, and so standard C has always been very close to a strict subset of what is going on in the world (otherwise normalization would fail miserably, of course). It is probable that I know a superset of your standard C. What I mean is I don't think (though not sure) that there are constructs that your standards define that I have not used or know how to use, and I do know how to do C stuff that your standards don't define (like subtracting the 2 pointers of Michaels comment and get a valid predictable reliable result).

I do program microcontrollers in C, not your standard C subset, and my code is valid. <insert crappy denial here>. Yes it is. <show that you missed the point>. It is valid. <say that if it is not standard C then it is not valid C>. No, you are wrong, it is valid C. <say I'm dumb>. Ok, granted, but it is still valid C. <say I should learn standards before I say something ignorant about what is valid C>. Try to understand that the rest of the World was here first. Dennis Ritchie defined C first, not you nor the standards. Guys who learned from him and his book do know C. And they didn't stop knowing C because standards appeared. On the contrary: the standards turned out to be a subset of what they know as C. And that was called "standard C". You and your standards just followed and tried to take over "what C is". But you don't define "what C is", you just defined "what standard C is".

And that "standard C" includes *ONE* definition of "valid". But you are not there yet to be able to claim that if it doesn't conform to what your standard says then it is "not valid C". You can say, instead, "not valid standard C". The rest of the world has *HUNDREDS* of definitions of what valid is (probably related to the probability of getting something to work).

Many such instances of C are in memory mapped devices where code *is only valid if the pointer difference is reliable always*. Such instances don't give a crap about your "standard definition for valid C", and (I know now) they are right to do so.

So it is just down arrogant of you to think your standards definition is applicable to every one on Earth for all perpetuity throughout the universe. Your brain is just too formatted to it by now that you don't even notice how arrogant that is.

The most you can say is that "is not valid according to the standard", so never try to generalize what "valid C" means (or think it is somehow implicit) because you came about just too late for that: Ritchie was here before you (as many many many many others). That arrogance does make you look like an idiot. <insert yadda yadda yadda standards bla bla GCC is conformat bla bla bla you're the biggest dumbest troll ever yadda yadda yadda>. Ok, but I'm right and you are wrong. Be a man about it. Use your words right.


> You are welcome to use any definition of valid in your personal conversations,
> but in the context of a compiler which aims to conform to the ISO standards you
> don't get to decide what the definition of valid is.  And this bugzilla is,
> most certainly, in the context of GCC.


Right. And in the context of Rilhas I'm not a troll, I'm super-dandy-Mr.-Rilhas, ok?? Use the correct words when talking to me. When talking to me you don't get to decide what a troll is, got it??

Are you for real?? In Bugzilla, as with any other place on Earth, we use our words and our concepts right. Not specific ones that you implicitly decided are the context for the conversation just because you said so or because *you think* everyone shares (or must share) with you. I didn't see any such definition before I came here, nor before your posts, so don't assume it because you will be wrong. Even if not always at least some times (like now). If that is what you meant then you should have explained it beforehand.

It is just wrong (possibly worse) of you to start a discussion where you say "bacon and eggs is light food" and in the middle of it (when you realize people are shooting you down for what you said) you decide that "ah, I use a previously defined <bacon and eggs> expression when referring to <lettuce> that I didn't warn you about, and in that context you have been wrong all along and I've been right! Na-na-na-na!!!". Just grow up. That looks like kid talk. Valid is valid. Period. Didn't you know I had previously defined the word "troll" to be "clever"? What? I didn't tell you? Well, I didn't need to, in the context of Rilhas (the one we are using) you've been calling me sweet things all along. Nice... :-) That's just dumb. Don't try to imply a narrow context when making generic claims. Use propper words and expressions.



> If you want to discuss other uses of "valid" or non-standard code, do it
> somewhere else, such as the comp.lang.c newsgroup.

Yes, I could too. And at home. And at the office. Even here. Even in Wikipedia. I'm free, or didn't you know? Just reply "out of order: here we just talk standards" and your problem will be solved and I'll be left talking to myself. However, don't try to say "valid" as a general word that in your mind means "valid in the context of standards" because I will not grant you that substitution right. Me, as a citizen of the world, deny you the right to take over a word such as "valid" because I come from a place where we have our own definition of "valid". So you are not allowed to substitute. Use "valid acording to the standards", that expression is free for the taking. Use it. Or just move out of the conversation and say "valid outside standards is out of my scope" or something like that. That is a good way to keep your messages "valid"... :-)))


> G++ doesn't compile that code because the code is invalid, and binding
> non-const references to rvalues is unsafe, and C++ experts have decided that a
> conforming compiler should not allow it.  One reason for that is the following:
> class X { int i; }
> X& f(X& x) { return x; }
> int main()
> {
>     X& x1 = f( X() );
>     return x.i;
> }
> This code is unsafe because it accesses X::i after it has been freed.

Yes, I understand. That would be bad code, of course. And unsafe. But Microsoft thought (correctly) that that is probably not more dangerous than:

char& f(char* sp) { return sp[0]; }
int main()
{
    char* sp=strdup("hello");
    char& c=f(sp);
    free(sp);
    return c;
}

I already know how to avoid such unsafe code. If I don't I'll learn when it crashes. (let me look again to see if it crashes before you point out I'm an idiot... ok, I think it crashes... I think you'll get my point anyway, moving along... :-))

Standards do not help me here also. In fact, I consider this code to have the same conceptual problem as yours. So they may have exagerated about your code example. Anyway, the compiler could generate a warning or something and so implement standards+more anyway. Or let me select some option for that (some "non-conformant-please" checkbox). But that is not the point: it doesn't because it doesn't want to, got it.

So, again, I don't need nor asked you to tell me why GCC can't, that has not been the point. However, in this case, your tone is informative, which makes a big difference. That makes you the opposite of an idiot, obviously. And I've informed you that MSC can. That doesn't make me an idiot either. And I've said they were right to do so. Not an idiot yet. And I've informed you that I would like to have such a feature in GCC. Still not an idiot. Just 2 guys exchanging ideas, seems all pretty normal to me.


> The standard says it's not allowed, and G++ implements that.  You are free to
> say it should be different, but noone will agree with you.

... none of you. In Microsoft they would probably all agree (or at least the majority of them). And users like me would all agree too. So, again: there is a big world out there. Don't assume "none" will agree just because you and the people you know don't, it just looks arrogant and you're back to being an idiot again. (you didn't have to, just should selected a better word than "none")

Or in the context of GCC and Bugzilla "none" has been previously defined as "none of the people who really matter, i.e., any member of the Bugzilla bug track team and everyone that follow their opinions like the religious leaders that they are and that excludes anyone who doesn't agree and has been marked as an idiot troll"? Plus "standards comities"? Plus "C++ experts"? Plus "their moms and dads and next of kin"? ... sorry, I missed it.