Re: [Boost-users] [boost.serialization] serialization crash

From: Johan Råde (rade_at_[hidden])
Date: 2006-11-01 12:46:03

Robert Ramey wrote:
> Johan Råde wrote:
> 
>>> But no one has been motivated to actually do this so far.
>> I'm working on such facets still for handling non-finite floating  point numbers.
> Sorry, I should have mentioned this.  I had thought that the idea
> of trapping the undefined behavior was abandoned for lack of
> interest.  

There was no lack of interest.
You were interested, and that suffices.

> I'm glad to see I was wrong about this.  I looks like you might want to include bools in this as well.

That would be trivial, just a few lines of code.
(IMHO  serializing an initialized bool is a very very bad idea,
but if it is of use to anyone, why not allow it to be done safely.)
All that is needed is a facet derived from std::num_put
with a virtual function like this:

   ... my_num_put::do_put(..., bool b)
   {
     if(b)
       b = true;
     else
       b = false;
     std::num_put::do_put(..., b);
   }

This will replace an uninitialized bool with an unspecified
initialized bool, before serializing it.

I will add this to nonfinite_num_put.

I do not believe it is possible to detect and trap an uninitialized bool.

> As I recall, part of the problem with "trapping" was which exception
> to throw.  Maybe this might be best handled the way other
> stream errors are handled - by setting a status flag and requiring
> that the user check it.

The problem is that the formatting facets
(such as std::num_put and facets derived from std::num_put)
do not have access to the the stream state.
Only parsing facets
(such as std::num_get and facets derived from std::num_get)
have access to the stream state.

It seems that the designers of the IOStreams library assumed
that formatting always succeeds.
I believe they made a design error here.

The best solution I could think of
was to have the facet throw an exception.

This leads to unspecified behaviour:

1. the exception may propagate through the stream object,
2. the stream may catch the exception and rethrow it
3. the stream may catch the exception and throw another exception
4. the steram may catch the exception and set the failbit
5. the stream may catch the exception and set the badbit

But dealing with this is not too bad,
as long as you are aware of it.

> As you can see, this is a recurring topic.  I believe it will be
> helpful to serialization, lexical_cast and perhaps others.  Also
> it may appeal to those of us programmers with slightly
> "paranoid" personalities who are convinced that everyone
> else is out to catch us.

The current status of the project is that I need
robust and portable isnan, signbit, and changesign functions.
I'm pursuing an approach based on examining the bit-patterns
of the numbers.
It all works, except for long double on Itanium processors.
I'm investigating that problem.

John Maddock is also working on these functions.

Stay tuned.

--Johan