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:39:54 GMT
Lines: 53
Message-ID: <9rouva$lvs$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> <9rot1m$l0v$1 AT news DOT itfs DOT nsk DOT su>
NNTP-Posting-Host: idisys.iae.nsk.su
X-Trace: news.itfs.nsk.su 1004535594 22524 193.124.169.11 (31 Oct 2001 13:39:54 GMT)
X-Complaints-To: usenet AT news DOT itfs DOT nsk DOT su
NNTP-Posting-Date: 31 Oct 2001 13:39:54 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

In comp.os.msdos.djgpp Michael N. Filippov <michael AT idisys DOT iae DOT nsk DOT su> wrote:
> 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 ?
>  

Just found what happens reading source code. Everything works fine if enable 
exceptions manually: oss.exceptions(ios::failbit | ios::badbit) it starts 
to throw ios_base::failure. Not as informative as bad_alloc (e.what() 
contains this "basic_ios::clear(iostate) caused exception"), but at 
least we can have handler instead of testing each <<.

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