Re: [Boost-users] [Boost String Algorithms library] ireplace_all bug with character arrays]

From: Pavol Droba (droba_at_[hidden])
Date: 2008-01-13 08:57:27

Hi,

Thorsten Ottosen wrote:
> shunsuke skrev:
>> Richard Turrin wrote:
>>> Hi,
>>>
>>> I've encountered a bug with ireplace_all from the Boost String 
>>> Algorithms library for version 1.35.  If I pass a character array for 
>>> the Format argument, the function ignores the null terminator and 
>>> instead uses the entire array minus the last character to replace the 
>>> occurrences of the Search string in the Input parameter.  However, if 
>>> I provide a pointer to a character array, the string replacement is 
>>> done as expected.
>>>
>>> When I stepped into the code, I came across the following lines 
>>> (excerpt from /trunk/boost/range/as_literal.hpp):
>>>
>>> template< class Char, std::size_t sz >
>>> inline iterator_range<const Char*> as_literal( const Char (&arr)[sz] )
>>> {
>>>     return boost::make_iterator_range( arr, arr + sz - 1 );
>>> }
>>>
>>> There is no check for a null terminator.  Nor did I find one after 
>>> this function returned.  I think the author here assumed that a 
>>> caller would always pass in a character array of the right size.
>>
>> Character array seems to have three views.
>>
>> 1. array: SIZE("ab\0c") == 5;
>> 2. literal: SIZE("ab\0c") == 4;
>> 3. null-terminated: SIZE("ab\0c") == 2;
>>
>> Both 2. and 3. is forced into boost::as_array.
>> "One name, two facilities" usually makes trouble.
>> IMO, `as_c_str` should have been added for 3.
> 
> I agree we could add a new function. Can we come up with a better name 
> than as_c_str()?
> 
> Or should we simply make as_literal() scan the array?
> 

I think, that as_literal should behave the same way for character arrays
and for c-string. Different behaviour is unexpexted here.

The only difference that could be beneficial is that for arrays, the
scanning for nulls can be bounded to protect agains the buffer overruns.

Regards,
Pavol.