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

["gdr at integrable-solutions dot net" <gcc-bugzilla@gcc.gnu.org>]

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