This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [James W.McKelvey <mckelvey@maskull.com>] Erroneous Comparisonsof Negative Characters
- From: Paolo Carlini <pcarlini at suse dot de>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: libstdc++ at gcc dot gnu dot org, Nathan Myers <ncm at cantrip dot org>
- Date: Mon, 03 May 2004 13:06:49 +0200
- Subject: Re: [James W.McKelvey <mckelvey@maskull.com>] Erroneous Comparisonsof Negative Characters
- References: <m3ad0qv7i1.fsf@uniton.integrable-solutions.net>
Thankg Gaby for the forward!
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
This /C standard conforming behavior/ (C99, 7.21.4, p1) seems at the
heart of the problem.
Indeed, a pedantic interpretation of Table 37 appear to imply that the C
functions, always defined in terms of /unsigned/ chars, cannot be used
for implementing traits::compare. And, we cannot overlook this as a
futile technicality (*), since, according to the current standard,
traits::compare /must/ be used in implementing string::compare.
Shall we perhaps fall back to the slow generic implementation, following
the letter of the standard? Personally, I'm not happy with this either,
since string::compare would give results different from std::strcmp!
What do other people think?
Paolo.
(*) I know that nobody likes that much char_traits today... ;)