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


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