[prev in list] [next in list] [prev in thread] [next in thread]
List: boost
Subject: Re: [boost] [outcome] some problems compiling
From: Niall Douglas via Boost <boost () lists ! boost ! org>
Date: 2017-05-26 13:09:13
Message-ID: 3378478f-bfda-5a32-db0a-8e8248a2c34e () nedprod ! com
[Download RAW message or body]
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::vector<std::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::vector<std::string>, perhaps returning a std::unique_ptr<char**,
> c_free> 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::vector<std::string> return value. It avoids both
> issues.
Agreed.
Niall
--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic