Boost logo

Boost Users :

From: David Abrahams (dave_at_[hidden])
Date: 2005-11-17 18:47:57


Daryle Walker <darylew_at_[hidden]> writes:

> On 11/13/05 10:01 AM, "David Abrahams" <dave_at_[hidden]> wrote:
>
>> Daryle Walker <darylew_at_[hidden]> writes:
>>
>>> Reading from an uninitialized variable, like what could happen in the
>>> original case during encoding, is not a problem any library can fix. The
>>> programmer just has to be non-sloppy.
>>
>> I buy Robert's argument that, in the case of bool, the assertion will
>> often help him diagnose the problem and help his users when they
>> complain that the library isn't working because they forgot to
>> initialize something.
> [TRUNCATE]
>
> Since Robert's test involves undefined behavior, it's not portable.

The test is completely portable. The function's requirements are that
the data passed is valid. Under those circumstances the test is
completely valid. If the user passes an uninitialized bool he has
already invoked undefined behavior and all bets are off.

> The assert may work on his system but may crash & burn on a
> different environment.

It can only crash and burn if the user has already invoked undefined
behavior by passing an uninitialized bool, and in that case leaving
out the assert is no protection against a crash -- the library is
about to read the bool in order to write it into the stream, which
reading is just as likely to cause the same crash.

> The assert didn't help the second user at all.

The second user?

> And what happens if the uninitialized variable just happens to match
> a valid state?

The bug goes undetected for now, and the assert neither helps nor
hurts.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net