libstdc++/325

[Heiko.Scheit@mpi-hd.mpg.de]

The following reply was made to PR libstdc++/325; it has been noted by GNATS.

From: Heiko.Scheit@mpi-hd.mpg.de
To: Phil Edwards <pedwards@disaster.jaj.com>
Cc: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, neil@gcc.gnu.org
Subject: Re: libstdc++/325
Date: Wed, 31 Jan 2001 00:51:02 +0100 (CET)

   This message is in MIME format.  The first part should be readable text,
   while the remaining parts are likely unreadable without MIME-aware tools.
   Send mail to mime@docserver.cac.washington.edu for more info.
 
 --8323328-841025282-980897692=:2739
 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
 Content-ID: <Pine.LNX.4.21.0101310038471.2739@pcheiko.mpi-hd.mpg.de>
 
 
   A C++ string (contrary to the common C (NUL-terminated) string)
   knows how long it is and there is no reason to treat any char(acter)
   in a special way.  Therefore I should be able to create a string
   like
 
       string test("\0\0\0\0\0");
 
   So, should the programmer take care and write
   '\0'+'\0'+'\0'+'\0'+'\0' or should the compiler take care.  Is it
   possible for the compiler to take care?
 
   By the way, when I run the test program that I submitted in the
   original bug report, string::find() does NOT return zero but
   string::size(), which is wrong in any case.
 
 % ./a.out
 test.size() =4
 test.find("\0") =4
 
   Actually, why does test.find_last_of("\0") give the right result?
 
   It seems there is another problem (Should I submit another bug report?):
   The two blocks below give different results...  (see the attached test.cc)
   {
     string test("");
     test+='a';
     test+='\0';
     test+='b';
     test+='\0';
     cout<<"5: "<<test<<endl;
     cout<<"len: "<<test.size()<<endl;
   }
   {
     string test("");
     test='a'+'\0'+'b'+'\0';
     cout<<"6: "<<test<<endl;
     cout<<"len: "<<test.size()<<endl;
   }
 
  
 On Sat, 27 Jan 2001, Phil Edwards wrote:
 > 
 > So... should a string literal consisting only of the NUL character (with
 > an implied second NUL terminator) become an empty string?  
 
   It should become an empty C string but NOT an empty C++ string.
 
 > What is the
 > correct behavior for memcmp when one of its arguments is an empty string?
 
   An empty string should always be matched, that is fine, I think.
 
 > And when the limiting character count is zero?  What is the sound of one
 > string matching?  :-)
 > 
 > The above call to memcmp returns zero, a match.  Since memcmp matches on
 > the very first call, the string::find() returns a position of 0 -- which
 > is correct as far as string::find knows.
 
   Well, I don't get a return value of 0 for string::find()...
 
   Greetings, Heiko
 
 --8323328-841025282-980897692=:2739
 Content-Type: TEXT/X-C++SRC; NAME="test.cc"
 Content-Transfer-Encoding: BASE64
 Content-ID: <Pine.LNX.4.21.0101310034520.2739@pcheiko.mpi-hd.mpg.de>
 Content-Description: 
 Content-Disposition: ATTACHMENT; FILENAME="test.cc"
 
 I2luY2x1ZGUgPHN0cmluZz4NCiNpbmNsdWRlIDxpb3N0cmVhbT4NCg0KaW50
 DQptYWluKCl7DQogIHsNCiAgICBzdHJpbmcgdGVzdCgiYWJjIik7DQogICAg
 Y291dDw8IjE6ICI8PHRlc3Q8PGVuZGw7DQogICAgY291dDw8ImxlbjogIjw8
 dGVzdC5zaXplKCk8PGVuZGw7DQogIH0NCiAgLyogc29tZSBlc2NhcGVzIGNo
 YXJzIC4uLiAqLw0KICB7DQogICAgc3RyaW5nIHRlc3QoImFiY1xuXHRkZWYi
 KTsNCiAgICBjb3V0PDwiMjogIjw8dGVzdDw8ZW5kbDsNCiAgICBjb3V0PDwi
 bGVuOiAiPDx0ZXN0LnNpemUoKTw8ZW5kbDsNCiAgfQ0KICAvKiBcMCBkb2Vz
 IG5vdCB3b3JrICovDQogIHsNCiAgICBzdHJpbmcgdGVzdCgiYVwwYlwwY1ww
 XDBcMGFcMCIpOw0KICAgIGNvdXQ8PCIzOiAiPDx0ZXN0PDxlbmRsOw0KICAg
 IGNvdXQ8PCJsZW46ICI8PHRlc3Quc2l6ZSgpPDxlbmRsOw0KICB9DQogIC8q
 IGxpa2UgdGhpcyBpdCB3b3JrcyAqLw0KICB7DQogICAgc3RyaW5nIHRlc3Qo
 IiIpOw0KICAgIHRlc3QrPSdhJzsNCiAgICB0ZXN0Kz0nXDAnOw0KICAgIHRl
 c3QrPSdiJzsNCiAgICB0ZXN0Kz0nXDAnOw0KICAgIHRlc3QrPSdjJzsNCiAg
 ICB0ZXN0Kz0nXDAnOw0KICAgIHRlc3QrPSdcMCc7DQogICAgdGVzdCs9J1ww
 JzsNCiAgICB0ZXN0Kz0nYSc7DQogICAgdGVzdCs9J1wwJzsNCiAgICB0ZXN0
 Kz0nYic7DQogICAgY291dDw8IjQ6ICI8PHRlc3Q8PGVuZGw7DQogICAgY291
 dDw8ImxlbjogIjw8dGVzdC5zaXplKCk8PGVuZGw7DQogIH0NCiAgLyogIGl0
 IHNlZW1zIHRoZXJlIGlzIGFub3RoZXIgcHJvYmxlbSAuLi4gKi8NCiAgew0K
 ICAgIHN0cmluZyB0ZXN0KCIiKTsNCiAgICB0ZXN0Kz0nYSc7DQogICAgdGVz
 dCs9J1wwJzsNCiAgICB0ZXN0Kz0nYic7DQogICAgdGVzdCs9J1wwJzsNCiAg
 ICBjb3V0PDwiNTogIjw8dGVzdDw8ZW5kbDsNCiAgICBjb3V0PDwibGVuOiAi
 PDx0ZXN0LnNpemUoKTw8ZW5kbDsNCiAgfQ0KICB7DQogICAgc3RyaW5nIHRl
 c3QoIiIpOw0KICAgIHRlc3Q9J2EnKydcMCcrJ2InKydcMCc7DQogICAgY291
 dDw8IjY6ICI8PHRlc3Q8PGVuZGw7DQogICAgY291dDw8ImxlbjogIjw8dGVz
 dC5zaXplKCk8PGVuZGw7DQogIH0NCn0NCg0K
 --8323328-841025282-980897692=:2739--