This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters
- From: "gdr at integrable-solutions dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 5 May 2004 18:32:42 -0000
- Subject: [Bug libstdc++/15276] Erroneous Comparisons of Negative Characters
- References: <20040504045136.15276.mckelvey@maskull.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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