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 libstdc++/15276] Erroneous Comparisons of Negative Characters


------- Additional Comments From gdr at integrable-solutions dot net  2004-05-05 18:32 -------
Subject: Re:  Erroneous Comparisons of Negative Characters

"sebor at roguewave dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Subject: Re:  Erroneous Comparisons of Negative Characters
| 
| pcarlini at suse dot de wrote:
| 
| ...
| > But I also think that typedef-ed or not-typedef-ed ;) v3 basic_string
| > lives in a world full of C strings, compared using strcmp and co (I'm
| > particularly concerned by the two string::compare overloads comparing
| > *this with a C string) and full of other respectable implementations
| > that are all strictly speaking incorrect all in the very same way
| > (that sketched by Josuttis, p.690, by the way)
| 
| Maybe it's lt() that needs to be fixed to behave like memcmp(), not
| compare() to behave like lt(). AFAICS, the standard does not require
| that lt() return the same value as operator<().

The standard does.  The whole point of this issue is precisely that.


The standard clearly says that lt() should match operator<().  I can
see what Paolo wants, but that is different from what is specified.
I think any reasoning based on a ghost consistency with C string
is just going to make the issue messier and more confused.

-- Gaby


-- 


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


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