Re: [Boost-users] boost::filesystem::path operator/= is broken for char[1] in 1.48

Subject: Re: [Boost-users] boost::filesystem::path operator/= is broken for char[1] in 1.48
From: Nat Linden (nat_at_[hidden])
Date: 2012-04-21 11:33:17

On Fri, Apr 20, 2012 at 1:15 PM, Ovanes Markarian
<om_boost_at_[hidden]> wrote:

> On Fri, Apr 20, 2012 at 6:08 PM, Nick Zavaritsky <mejedi_at_[hidden]> wrote:

>> boost::filesystem::path         some_path("first");
>> char                                    path_component[1]; /* = "second"
>> */
>> some_path /= path_component;
>>
>> Some_path value is expected to be "first/second" but it is "first".
>> I.e operator /= had no effect.

> I think the idea behind this is that any char* related string must be null
> terminated. So char[1] has only place for '\0'...

>> This technique is often used in C code.

> if you
> know that this buffer represents some special case, why don't you pass it as
> such to filesystem? &char[0], than boost::filesystem will not assume it got
> char[1] and will be looking to '\0' marker...

I strongly agree with Ovanes.

>> I believe the current operator =/ behavior is outright dangerous and
>> should be fixed.

Nope, sorry. If you pass a fixed-length array, a proper C++ library
*should* be sensitive to its max. Anything else is unsafe and should
be discouraged.

In the early days of C, people played all sorts of tricky games
because (a) the language didn't support any better alternatives and
(b) there was this cowboy mentality of "structured assembler."

The fact that we're still dealing with legacy C-style APIs is not a
good reason for a modern C++ library to blithely run past the declared
end of a char array. C++ tries very hard to bring type-safety to the
party. It is far more important to try to keep new code from crashing
than it is to accommodate such misleading APIs.

When you know you're dealing with code that willfully lies to the
compiler -- even if it's been frozen into an OS API -- use Ovanes's
workaround to pass char* rather than char[size]. To protect your
fellow coders from the crufty details, wrap it in a function layer
that obeys language rules.