From: "Michael N. Filippov" <michael AT idisys DOT iae DOT nsk DOT su>
Newsgroups: gnu.g++.help,gnu.gcc.help,comp.os.msdos.djgpp
Subject: Re: ostringstream / not enough memory
Date: 31 Oct 2001 13:07:02 GMT
Lines: 47
Message-ID: <9rot1m$l0v$1@news.itfs.nsk.su>
References: <9rong5$i1m$1 AT news DOT itfs DOT nsk DOT su> <pan DOT 2001 DOT 10 DOT 31 DOT 13 DOT 28 DOT 35 DOT 881 DOT 26631 AT spamproofemail DOT com>
NNTP-Posting-Host: idisys.iae.nsk.su
X-Trace: news.itfs.nsk.su 1004533622 21535 193.124.169.11 (31 Oct 2001 13:07:02 GMT)
X-Complaints-To: usenet AT news DOT itfs DOT nsk DOT su
NNTP-Posting-Date: 31 Oct 2001 13:07:02 GMT
User-Agent: tin/pre-1.4-19990517 ("Psychonaut") (UNIX) (Linux/2.4.3 (i586))
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

I dont have copy of the standard either, but looks you're right:
adding test like this (found them in ios_base.h)
      if (!oss) {
        if (oss.rdstate() & ios::goodbit)
          cerr << "goodbit" << endl;
        if (oss.rdstate() & ios::eofbit)
          cerr << "eofbit" << endl;
        if (oss.rdstate() & ios::failbit)
          cerr << "failbit" << endl;
        if (oss.rdstate() & ios::badbit)
          cerr << "badbit" << endl;
        break;
      }
shows that oss is in "bad" state after last operation. (in 2.95.2  version it 
called bad_alloc). Problem is: Not so simple to roll back last (failed) 
operation for it appends only part of the string. And hard to understand what 
happened. Shoulds it really do this (just set badbit) or throw bad_alloc ?
 


In comp.os.msdos.djgpp Tim Van Holder <notme AT spamproofemail DOT com> wrote:
>> int main(void)
>> {
>>   char* buffer(0);
>>   const size_t buffer_length(1 * 1000 * 1000);

> I find it very odd style to use constructor syntax for non-object types.
> What's wrong with 'const size_t buffer_length = 1 * 1000 * 1000'?

>>   [snip]
>>   delete buffer;

> should be delete[]

>> I see that if there is not enough memory string just stops growing. BTW
>> - same code with my previous configuration (GCC 2.95.2, same <sstream>)
>> caused SIGABRT from throw_helper (it couldn't find exception handler I
>> suppose)
>> 
>> I would expect that in this example/ code should throw bad_alloc (like
>> if using not ostringstream. but just std::string of std::vector).

> If it does run out of memory, it should probably throw, yes.
> It would have helped to see the program's output though; you may also
> want to print the values of oss's badbit and failbit; it might be that
> all it is required to do by the standard is set failbit on overflow
> (don't have a copy of the standard handy right now).