Re: [boost] [outcome] some problems compiling

On 26/05/2017 00:57, Gavin Lambert via Boost wrote:

On 26/05/2017 02:42, Niall Douglas wrote:

...

...

Why doesn't this just return std::vectorstd::string or some kind of smart pointer for avoidance of doubt and exception-safety? It feels like this is allowing implementation details to escape unsafely.

The implementation literally returns what backtrace_symbols() returns, which is a malloced char **.

I assumed that, hence my comment about a leaking implementation detail. That's a reasonable return value for a C library like backtrace_symbols; it's bad style for a C++ library.

If you don't want the expense of copying the strings individually to a std::vectorstd::string, perhaps returning a std::unique_ptr would be a reasonable compromise for that specific issue, although that still masks the array-ness so it's not ideal.

That's a fair point. Logged to https://github.com/ned14/boost.outcome/issues/45.

The other problem with this API as it stands is that it provides no way to convey the actual number of frame strings returned. backtrace_symbols() in the underlying library makes no guarantee to null-terminate the array, as far as I can tell. raw_backtrace(), or backtrace() in the underlying library, does give you the number of frames filled but this information is not available to the caller of error_code_extended::backtrace() unless they call raw_backtrace() separately, which seems pointless.

And you've just discovered an exceeding bounds bug. Thank you very much. Logged to https://github.com/ned14/boost.outcome/issues/46.

Since symbolising the trace is inherently an expensive operation anyway I don't think it's worth worrying about avoiding the copy, which is why I suggested the std::vectorstd::string return value. It avoids both issues.

Agreed. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/