Re: [Stlport-devel] exceptions

[<fra...@fr...>]

    bad_alloc do not use __Named_exception. In the most usual case, 
bad_alloc exception is defined by native library as it is thrown by new 
operator that STLport do not redefine. Even with limited native 
libraries having no bad_alloc, STLport own bad_alloc do not use 
__Named_exception as C++ Standard in 18.4.2.1 do not require a bad_alloc 
constructor taking a message. So this patch has no impact on bad_alloc 
and __Named_exception shall never be raised in an out of memory context 
except if a user badly return a runtime_error exception for instance in 
such a case which is of course bad coding practice.

    I intentionally use malloc in this new implementation to avoid an 
additional exception to be raised. See C++ Standard 15.5.1 note 134, if 
I throw an exception in __Named_exception constructor, terminate 
function will be called. I preferred to keep the original failure reason 
even if exception message is truncated. The reason for static buffer is 
historical, I had never notice it before a mail from you, Uli, saying 
that your message was truncated in STLport exceptions. IMO historical 
reason was simply to limit system calls in exception handling process 
which I consider as good practice, this is why I keep it. This is like 
the sizeof(char), do the C++ or rather C Standard really specify that it 
must be 1, I didn't want to check it so I simply took sizeof. I will fix 
change C cast.

Bests


Ulrich Eckhardt wrote:
> On Wednesday 16 May 2007 07:59, Petr Ovtchenkov wrote:
>   
>> +       * stlport/stl/_stdexcept_base.h, _stdexcept_base.c:
>> __Names_exception +       do not truncate anymore exception message when
>> longer than internal +       static buffer, a dynamic buffer is allocated
>> through malloc in this +       case. I haven't use __iostring class in this
>> case as it would +       have introduce a cyclic dependency between
>> classes.
>>
>>
>> +__Named_exception::__Named_exception(const string& __str) {
>> +  size_t __size = strlen(__get_c_string(__str)) + 1;
>> +  if (__size > _S_bufsize) {
>> +    _M_name = (char*)malloc(__size * sizeof(char));
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> +    if (_M_name == 0) {
>> +      __size = _S_bufsize;
>> +      _M_name = _M_static_name;
>> +    }
>> +  }
>> +  else {
>> +    _M_name = _M_static_name;
>> +  }
>>
>>
>> Well, and what about bad_alloc and exception due to memory limits?
>>     
>
> bad_alloc must not use this, I absolutely agree. If other exceptions use this, 
> and you are already so short on memory that allocation fails, it makes little 
> difference if the construction of the exception causes a bad_alloc, only 
> constructing the bad_alloc must not cause an allocation failure.
>
> That said, I don't like above code either. The reason is that I throw a long 
> string, and if allocation fails it silently gets truncated. My main problem 
> with this is that there is a silent failure, I'd much rather have a bad_alloc 
> thrown at me instead. What is the rationale for the fixed-size buffer? What 
> is the rationale for truncating instead of signalling the allocation failure?
>
> Further, I'd prefer C++ casts and sizeof char is always by definition 1.
>
>   
>> IMO no dynamic allocation should happen during exception generation.
>>     
>
> Why? bad_alloc is a special case, as it is a result of dynamic allocation 
> failure, but other exceptions can well use strings. They even have to, 
> according to the standard, like e.g. runtime_error, which carries a string.
>
> Uli
>
>