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


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

[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters



------- Comment #33 from matz at gcc dot gnu dot org  2010-08-12 18:56 -------
> 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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265


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