[Bug libstdc++/15276] New: Erroneous Comparisons of Negative Characters

[Bug libstdc++/15276] New: Erroneous Comparisons of Negative Characters

[mckelvey at maskull dot com]

When chars are implemented as signed, characters with negative values compare 
properly as individual chars, but improperly when part of a char array or 
std::string -- they compare as unsigned. The problem appears to be that the 
specialization of std::char_traits<char> uses memcmp. This is observed on an 
Alpha running RH 7.1 and gcc version 3.5.0 20040207.

Specifically, std::char_traits<char>::compare is inconsistent with 
std::char_traits<char>::lt, which affects std::string (which is just 
std::basic_string<char>.) The problem also affects strcmp, strncmp, and 
strcoll.


Result of running test program, with my analysis:

122      Expected character value of 'z'.
-64      Expected value of signed character '\0300'
192      Expected value of unsigned character '\0300'
-64      Shows that chars are signed

SC 1    Expected character comparison as signed char
UC 0    Expected character comparison as unsigned char
CH 1    Expected character comparison as char (signed)
SV 1    Demonstrates that std::string::value_type is signed
ST 0    Error: std::string of length 1 does not compare the same as CH
BS 1    std::basic_string<signed char> compares as expected
BU 0    std::basic_string<unsigned char> compares as expected
BC 0    Error: Same as ST, as expected (std::basic_string<char>)
TS 1    std::char_traits<signed char> compares signed char * as expected
TU 0    std::char_traits<signed char> compares unsigned char * as expected
TC 0    Error: std::char_traits<char>, char * does not compare properly
LS 1    std::char_traits<signed char> compares signed char as expected
LU 0    std::char_traits<unsigned char> compares unsigned char as expected
LC 1    std::char_traits<char> compares char as expected
          (Note: inconsistent with TC)
MC 0   std::memcmp is comparing as unsigned (I guess that's OK)
SC 0    Error: std::strcmp is comparing as unsigned
SN 0    Error: std::strncmp is comparing as unsigned
SL 0     Error: std::strcoll is comparing as unsigned

-- 
           Summary: Erroneous Comparisons of Negative Characters
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mckelvey at maskull dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: alphaev56-unknown-linux-gnu
  GCC host triplet: alphaev56-unknown-linux-gnu
GCC target triplet: alphaev56-unknown-linux-gnu


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[mckelvey at maskull dot com]

------- Additional Comments From mckelvey at maskull dot com  2004-05-04 04:53 -------
Created an attachment (id=6218)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6218&action=view)
C++ program demonstrating the problem.


-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-04 05:14 -------
Well a simple C program shows that std::strcmp just uses the C code:
#include <string.h>
int main()
{
int i = strcmp("z", "\300");
  printf("%d\n", i);
}

So I do not know if this is a bug as it is negative on powerpc-darwin and i686-pc-linux and i686-
unknown-openbsd3.1 which all uses different libc.

-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-04 09:33 -------
Some initial comments here:

  http://gcc.gnu.org/ml/libstdc++/2004-05/msg00009.html

FWIW, Icc8.0 behaves exactly the same of gcc.

I suspect that was is really needed is a clarification in the standard: the
specification for traits::compare, strictly speaking is inconsistent with
std::strcmp.

-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[mckelvey at maskull dot com]

------- Additional Comments From mckelvey at maskull dot com  2004-05-05 03:18 -------
>> I suspect that was is really needed is a clarification in the standard: the
>> specification for traits::compare, strictly speaking is inconsistent with
>> std::strcmp.

Well, instead, why not just have C++ work properly, as defined reasonably by the
standard in Table 37? std::strcmp is not mentioned, and is therefore irrelevant.
compare is inconsistent with lt; do you think that codifying that behavior is a
"clarification", or is it more akin to saying that, when convenient, 2 + 2 = 5?

Referring to the comments in

http://gcc.gnu.org/ml/libstdc++/2004-05/msg00009.html

there is nothing pedantic about the definition of compare in Table 37, it is
clearly and simply stated.


-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-05 08:27 -------
> "clarification", or is it more akin to saying that, when convenient, 2 + 2 = 5?

Since you are so sure about the way to go, why don't you implement it locally
for your own use and that's it?



-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[gdr at integrable-solutions dot net]

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

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From pcarlini at suse dot de  2004-05-05 08:27 -------
| > "clarification", or is it more akin to saying that, when convenient, 2 + 2 = 5?
| 
| Since you are so sure about the way to go, why don't you implement it locally
| for your own use and that's it?

This is the most unhelpful answer I've seen on this topic.

First, you started asserting that something is pedantic -- without
ever demonstrated that is actually the case.  
Now, you're telling him that he should implement the behaviour in his
local tree.  Then you come lecture people on PRs?
You got to be joking.

-- Gaby


-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-05 09:43 -------
> This is the most unhelpful answer I've seen on this topic.

Not less helpful than yours, which we are still waiting...

-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-05 09:56 -------
Admittedly, I become nervous when someone consider changing from one day to 
another string::compare behavior to become different from std::strcmp. Therefore,
please accept my excuses for my harsh response, but also, please, don't consider
the issue simpler than it is.

-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[gdr at integrable-solutions dot net]

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

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From pcarlini at suse dot de  2004-05-05 09:43 -------
| > This is the most unhelpful answer I've seen on this topic.
| 
| Not less helpful than yours, which we are still waiting...

Did you take the time to read my message, you would have noticed that
I gave my opinion -- I disgreed with your characterization that the
reading is pedantic.  But, I suppose you were more in hurry in showing
that yours is bigger than mine -- which I would not dispute.
I hope the rest of C++ guys at SuSE don't treat reports like you do
(at least, from what I've noticed, my reports (not C++ related) were
answered in meaningful and timely maner).

-- Gaby


-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[gdr at integrable-solutions dot net]

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

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| Admittedly, I become nervous when someone consider changing from one

I see a difference with being "nervous" and "being rude" for the
purpose of "intimidating".  IMNSHO, you've been lately in the
latter category than the former these months.

| day to another string::compare behavior to become different from
| std::strcmp. Therefore, please accept my excuses for my harsh
| response, but also, please, don't consider the issue simpler than it is.

The issue as I see it is quite simple:  The specification in table 37
regarding char_traits<>::compare is clear, and it takes an
extraodinary interpretation to conclude that string::compare 
and std::strcmp should match -- let alone the fact that std::string
already differs from  traditional C-style strings in the sene that
the former can contain nul characters whereas the later can't.

But, of course, that may be subtle to someone already convinced that a
C++ string is just a typedef-name for a C-string.

-- Gaby
 


-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-05 10:53 -------
> The issue as I see it is quite simple:  The specification in table 37
> regarding char_traits<>::compare is clear, and it takes an
> extraodinary interpretation to conclude that string::compare 
> and std::strcmp should match

Therefore, you don't think that tons of code around relies on that? And, if
a std::string and a "C" string are supposed to be so essentially different,
what is c_str() all about?

I think that the interpretation of the letter of the standard is easy, but,
at the same time, I think that, perhaps (I hope Nathan will provided soon
his opinion) this difference with "C" strings was not really intended. And
I think that the two specializations were actually meant to allow exploiting
for efficiency strcmp and wcscmp.

Are there other implementations around that actually use Table37 instead of
strcmp and wcscmp for char and wchar_t? I'm sure of one thing: the other
major implementation which often and often interworks with libstdc++-v3 doesn't.

-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-05 11:07 -------
(trivial) errata: of course I really meant memcmp and wmemcmp, not strcmp and
wcscmp. Nothing changes in my argument.

By the way, in the meantime, I have verified that two other, completely
independent, implementations, also use memcmp and wmemcmp. I can provide details,
in case.

-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[gdr at integrable-solutions dot net]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]


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

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| > The issue as I see it is quite simple:  The specification in table 37
| > regarding char_traits<>::compare is clear, and it takes an
| > extraodinary interpretation to conclude that string::compare 
| > and std::strcmp should match
| 
| Therefore, you don't think that tons of code around relies on that? And, if
| a std::string and a "C" string are supposed to be so essentially different,
| what is c_str() all about?

The issue at hand is entirely different.

The question is not that « std::string and "C" string are supposed to be
so different, nor what c_str() is all about.  » 

First, the pointer returned by c_str() is not necessary a C-string
equivalent of the "content" of std::string.

Secondly, assuming a std::string was supposed to be a typedef-name for
a C-string, we would not have had a c_str() in the first place.  That
is, that member function is precisely there to povide a C view of the
contents of std::string *when that makes sense*.  

A program that assumes that a std::string is an unconditional alias
for a C-string is broken and contains security hole, by definition.

But again, the issue at hand is different.  The issue at hand
concerns the specific implementation of comparaison we have in V3.

| I think that the interpretation of the letter of the standard is easy, but,
| at the same time, I think that, perhaps

Sure, it is hard to second guess what the committee intended -- a
truism -- specifically when one does not want to believe what it wrote.


-- Gaby


-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-05 12:05 -------
> Secondly, assuming a std::string was supposed to be a typedef-name for
> a C-string, we would not have had a c_str() in the first place.

Honestly, I don't understand why you are insisting on this 'typedef-name'
thing, that nobody has mentioned before. Are you referring to a previous 
discussion?

> Sure, it is hard to second guess what the committee intended -- a
> truism -- specifically when one does not want to believe what it wrote.

However, apparently, all the major implementations in the world are so
"perverse" to second guess like this... Do you really consider wise for v3
to diverge on this issue?

-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[gdr at integrable-solutions dot net]

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

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| > Secondly, assuming a std::string was supposed to be a typedef-name for
| > a C-string, we would not have had a c_str() in the first place.
| 
| Honestly, I don't understand why you are insisting on this 'typedef-name'
| thing, that nobody has mentioned before. Are you referring to a previous 
| discussion?

I'm referring to the current discussion and the way you seem to
perceive std::string, given your questioning.

| > Sure, it is hard to second guess what the committee intended -- a
| > truism -- specifically when one does not want to believe what it wrote.
| 
| However, apparently, all the major implementations in the world are so
| "perverse" to second guess like this... Do you really consider wise for v3
| to diverge on this issue?

Apparently, you want V3 to be "perverse".

I don't want V3 just to follow bindly.  I'm happy in establishing V3's
interpretation is correct, not that it is behaving like another
implementation that you think is "perverse".  If you can come up with
a rational sequence of inferences that makes V3 match the standard, I
would be most happy to explain it to the original submitter. But,
please, don't come and tell me that V3 is correct with respect to the
standard specification because someone else is doing the same.  

-- Gaby


-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-05 15:19 -------
> I'm referring to the current discussion and the way you seem to
> perceive std::string, given your questioning.

My only problem is that I don't know the appropriate typedef, acc! ;)

>                                                                  But,
> please, don't come and tell me that V3 is correct with respect to the
> standard specification because someone else is doing the same.

No, I think v3 is strictly speaking incorrect.

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)

Honestly, I don't feel like putting my name on a patch touching this,
at least not so quickly: I sent a message to comp.std.c++.

However, I understand your point of view, I know your position in the
committee, and your status of v3 maintainer. If you want to go ahead
I will not try to stop you.

-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-05-05 16:21 -------
Guys, just from an observer's perspective: do everyone a favor and take 
out the personal tone of this discussion. I know not everyone is everyone's 
friend, but this should really be a technical forum. 
Thanks 
  Wolfgang 

-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[gdr at integrable-solutions dot net]

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

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| 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)
| 
| Honestly, I don't feel like putting my name on a patch touching this,
| at least not so quickly: I sent a message to comp.std.c++.

It is one thing to refuse to endorse a given patch, it is another to
being rude and it is another to say "we're incorrect, but we're
unlikely to change our implementation". 

This is issue surfaces only when char is implemented as as signed  char.

The C standard is very clear in requiring that the sign of the
comparaison is that of the sign of the first non-null difference of 
respective characters (as unsigned char).  Because of that, some
compilers tend to map plain char, internally, to unsigned char to
minimize surprises.  And In those cases, using strcmp or whatever C
has does not make a difference, because the compiler mapping matches
the library expectations.

However, with char being signed, it is clearly a mistake to use
strcmp because its semantics does not reflect what table 37 says.  
(It can be argued whether table 37 means what it says, but if we're
going to be rude, we rather base on facts).

One way to solve this is to provide the generic version only when you
know that char is not unsigned -- in GCC, that is detectable with

   #if !defined(__CHAR_UNSIGNED__)

| However, I understand your point of view, I know your position in the
| committee,

You have to understand that I'm not coming to this issue as having any
position in the committee.

-- Gaby


-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-05 17:12 -------
> One way to solve this is to provide the generic version only when you
> know that char is not unsigned -- in GCC, that is detectable with
>
>   #if !defined(__CHAR_UNSIGNED__)

Thanks for the suggestion, which, actually, I had already (only vaguely)
envisaged in my mind. As you can easily imagine, I'm not super happy with this
solution, since at run time comparing a basic_string with a basic_string, and
a basic_string with a "C"-string will be done in a way, comparing a "C"-string
with a "C"-string in another, inconsistent, way (for signed char type)

Don't you find this rather unsatisfactory?

Anyway, let's wait a bit for feedback from comp.std.c++...






-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[gdr at integrable-solutions dot net]

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

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| > One way to solve this is to provide the generic version only when you
| > know that char is not unsigned -- in GCC, that is detectable with
| >
| >   #if !defined(__CHAR_UNSIGNED__)
| 
| Thanks for the suggestion, which, actually, I had already (only vaguely)
| envisaged in my mind. As you can easily imagine, I'm not super happy with this
| solution, since at run time comparing a basic_string with a basic_string, and
| a basic_string with a "C"-string will be done in a way, comparing a "C"-string
| with a "C"-string in another, inconsistent, way (for signed char type)
| 
| Don't you find this rather unsatisfactory?

No, they already compare differently (hint: think of a std::string
that contains a null character).  

-- Gaby


-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-05 17:35 -------
> No, they already compare differently (hint: think of a std::string
> that contains a null character).

I know well about *that* difference, but I'm not persuaded anyway, since the
same inconsistency happens considering basic_string-basic_string,
basic_string-char_array, char_array-char_array: again, the internals of
the two corresponding string::compare overloads would compare signed, memcmp
unsigned.



-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[sebor at roguewave dot com]

------- Additional Comments From sebor at roguewave dot com  2004-05-05 17:36 -------
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<().

Martin




-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-05 17:39 -------
> 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<().

Hi Martin! Unfortunately it does (noticed yesterday)! See 21.1.3.1, p6.

-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[sebor at roguewave dot com]

------- Additional Comments From sebor at roguewave dot com  2004-05-05 17:52 -------
Subject: Re:  Erroneous Comparisons of Negative Characters

pcarlini at suse dot de wrote:

> ------- Additional Comments From pcarlini at suse dot de  2004-05-05 17:39 -------
> 
>>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<().
> 
> 
> Hi Martin! Unfortunately it does (noticed yesterday)! See 21.1.3.1, p6.
> 

Yep, you're right. I missed it. What a mess!

Martin




-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-05 18:26 -------
> Yep, you're right. I missed it. What a mess!

Indeed, in my opinion too *is* a mess!

Interestingly, the 1995 draft even *prescribed* using memcmp and wmemcmp: a nice
task for the historian would be reconstructing *why* that section was removed.

Personally, barring evidence to the contrary, I'm still convinced that whoever
wrote the compare entry in Table 37 *at least* didn't want to rule out using 
memcmp and wmemcmp (on signed char platforms).

-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[gdr at integrable-solutions dot net]

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

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| > No, they already compare differently (hint: think of a std::string
| > that contains a null character).
| 
| I know well about *that* difference, but I'm not persuaded anyway, since the

Your question was whether I found the previous description you made
inconsistent; I was replying to that question -- which you chosed to
elide when replying.  Whether you know that difference does not make
the different behaviour more, or less, or just inconsistent.

| same inconsistency happens considering basic_string-basic_string,
| basic_string-char_array, char_array-char_array: again, the internals of

No, it does not.

-- Gaby


-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[gdr at integrable-solutions dot net]

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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[gdr at integrable-solutions dot net]

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

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| > Yep, you're right. I missed it. What a mess!
| 
| Indeed, in my opinion too *is* a mess!
| 
| Interestingly, the 1995 draft even *prescribed* using memcmp and wmemcmp: a nice
| task for the historian would be reconstructing *why* that section was removed.

That section was certainly removed for some reason -- it takes
committee vote to remove or add something to the working paper.

| Personally, barring evidence to the contrary, I'm still convinced that whoever
| wrote the compare entry in Table 37 *at least* didn't want to rule out using 
| memcmp and wmemcmp (on signed char platforms).

Wonderful.

-- Gaby


-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-05 18:42 -------
> The standard clearly says that lt() should match operator<().  I can
> see what Paolo wants, but that is different from what is specified.

Indeed, *many* messages ago, I replied the first to submitter writing that
perhaps the standard should be ""improved"".

> I think any reasoning based on a ghost consistency with C string
> is just going to make the issue messier and more confused.

About this, we slightly disagree: f.i., I don't think that eliding 21.1.3.1,p6
would be such a big win. Having to renounce to the support of well optimized
memcmp and wmemcmp it's not a little thing... Also, basic_string heavily
*interacts* with char arrays and C strings, always, and I don't think doing
the comparisons two different ways is a big win.

-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-05 18:56 -------
> About this, we slightly disagree: f.i., I don't think that eliding 21.1.3.1,p6
> would be such a big win. Having to renounce to the support of well optimized
> memcmp and wmemcmp it's not a little thing... Also, basic_string heavily
> *interacts* with char arrays and C strings, always, and I don't think doing
> the comparisons two different ways is a big win.

Sorry about that, actually is wrong. If we could really elide 21.1.3.1,p6, then,
as hinted by Martin (I think), lt() could always compare unsigned, irrespective
of builtin operator<(), and that would do the trick! Sorry again.

-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-05 19:14 -------
> I think any reasoning based on a ghost consistency with C string
> is just going to make the issue messier and more confused.

Actually, if some sort of consistency with memcmp & co, that is the C library
functions for C strings and char arrays, is not a requirement, the issue is not
messy *at all*: you just give away some performance and implement the letter of
traits::compare in Table 37.



-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[gdr at integrable-solutions dot net]

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

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| About this, we slightly disagree: f.i., I don't think that eliding 21.1.3.1,p6
| would be such a big win. Having to renounce to the support of well optimized
| memcmp and wmemcmp it's not a little thing...

It remains to be proved that they actually add preformance wins to
the std::string implementation we have.
Irrespective of what we decide, do you have data that supports your
claim that the memcmp for out implementation is a performance win for
typical uses for our std::string?   

-- Gaby


-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[gdr at integrable-solutions dot net]

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

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| > I think any reasoning based on a ghost consistency with C string
| > is just going to make the issue messier and more confused.
| 
| Actually, if some sort of consistency with memcmp & co, that is the C library
| functions for C strings and char arrays, is not a requirement, the issue is not
| messy *at all*: you just give away some performance and implement the letter of
| traits::compare in Table 37.

Sorry.  I really don't understand what you're trying to say in this
message. 

-- Gaby


-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-05-06 08:04 -------
> Sorry.  I really don't understand what you're trying to say in this
> message.

You wrote: "ghost consistency with C string is just going to make the issue
messier and more confused". I maintain that if we don't really care about
some sort of consistency with the "C" library, the "C" strings and the "old
style" treatment of char arrays, the issue is not _less_ messy, is not _less_
confused, is not confused _at all_.



-- 


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-06-20 09:48 -------
Confirm to...

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-06-20 09:48:28
               date|                            |


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-06-20 09:52 -------
... suspend it: the issue will be throughly discussed in Redmond.



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED


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

[Bug libstdc++/15276] Erroneous Comparisons of Negative Characters

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-26 21:11 -------
*** Bug 16720 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |g dot bonacci at libero dot
                   |                            |it


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

[Bug libstdc++/15276] [DR 467] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-08-05 10:59 -------
This is now DR 467 (New):

  http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#467

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Erroneous Comparisons of    |[DR 467] Erroneous
                   |Negative Characters         |Comparisons of Negative
                   |                            |Characters


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

[Bug libstdc++/15276] [DR 467] Erroneous Comparisons of Negative Characters

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-04-17 18:16 -------
This can be safely closed: in Lillehammer, the LWG moved the proposed resolution
of DR 467 to [Ready] (modulo a minor pasto in the first sentence) thus explicitly
mandating the behavior implemented by v3. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |RESOLVED
         Resolution|                            |INVALID


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