Re: [boost] [Review] Fixed Strings review period extended

From: David Abrahams (dave_at_[hidden])
Date: 2006-01-30 04:51:33

"Reece Dunn" <msclrhd_at_[hidden]> writes:

> Pavel Antokolsky aka Zigmar wrote:
>>For me personally, the reason I didn't submit any review, that I'm not
>>completely understand the purpose of the library. The documentation
>>(as few mentioned) lacks motivation and general description. So how
>>can I review the library, if I can't understand what the library is
>>trying to solve and how. I can't say for others, but for it is the
>>reason. I suggest that even if documentation can't be updated during
>>formal review, that the author will give a little more extended
>>explanation here, at mail list.
>
> The main aim of the library was presented in the "The Problem"/"The 
> Solution" sections (the first ones) of the documentation.
>
> Normally, in C (or even some C++ code), you have constructs that look like 
> this:
>
>    char buffer[ 15 ];
>    sprintf( buffer, "Some %s text", "verly long" );
>
> The problem is that the above would cause a buffer overrun, which is the 
> most common cause of denial of service attacks and other security holes in 
> major applications. The variant that allows you to specify the size of the 
> string buffer is better, but not prefect. Consider the following:
>
>    wchar_t buffer[ 5 ];
>    wcsncpy( buffer, sizeof(buffer), L"12345678" );
>
> At first glance, this code looks safe, but will also cause a buffer
> overrun. 
>
> The fixed_string class is designed to solve this problem. The above examples 
> would be:
>
>    fixed_string< 15, char > buffer;
>    sprintf( buffer, "Some %s text", "verly long" );
>
> and:
>
>    fixed_string< 5, wchar_t > buffer;
>    wcscpy( buffer, L"12345678" );

The reason I didn't submit a review was that I didn't have time.  But
more generally, I don't think fixed strings are the right tool for
this job 99% of the time.  A variable-sized string with small string
optimization will serve nicely, and if used properly, will virtually
eliminate the problem of buffer overruns.  I don't think we should be
encouraging people to patch their way around unsafe code in a way
that's still unsafe.

It's still unsafe because the code's original author expects the code
to work, not for it to throw an exception or truncate the input or
whatever the proposed library does.

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