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

Subject: Re: [Boost-users] boost::filesystem::path operator/= is broken for char[1] in 1.48 (Nat Linden)
From: ZNV (mejedi_at_[hidden])
Date: 2012-04-21 13:42:32

Hi Nat,

>> 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.
>

What if I pass fixed-length array without actually knowing that?
There are many C libraries out there assuming char * and char [] are
interchangeable.
These libraries are well documented.
You won't check the source code beforehand if you have the docs, will you?

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.
>

I totally agree with you – type safety is an important C++ feature.
It is supposed to help a programmer by eliminating more errors early.
But you've achieved just the opposite result with your creative abuse of
C++ type system.

I would've agreed with your resolution if appending char[1] to
boost::filesystem::path resulted in a static_assert.
This would allow to apply the proposed workaround immediately (cast to char
*).
Unfortunately boost::filesystem have chosen to break my code silently
instead.
I had to hunt the bug in debugger – the same very thing the type safety was
supposed to prevent, is not it?

So yes technically my program did not crash.
But I totally believe that it is not only preventing new code from crashing
which is important.
Eliminating obscure pitfalls the new code is suffering from is equally
important.

Every engineering problem is a quest for a better tradeoff.
Concerning appending fixed-length array of length one or less to a
boost::filesystem::path we are facing the following choices

1) silently treat the operation as a no-op (current)
2) treat it the same way as char *
3) static_assert

In my opinion (1) is the worst possible choice since it breaks the code
silently in a non-obvious way.

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].
>

See above.