Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues

Antony Polukhin wrote:

2016-12-18 20:26 GMT+03:00 Peter Dimov :

...

What I can suggest as a low-level API is:

// capture

typedef void (*stacktrace_frame)(); // a bit on the pedantic side, but why not

size_t stacktrace_capture( stacktrace_frame buffer[], size_t size );

That's doable. But how are you going to use it?

The majority of users will just construct a stacktrace high-level object, as today, which will use this in the constructor to capture. But people who'd rather go lower level can use this directly, and people who'd rather go even lower can capture a stack trace via other means, without depending on Stacktrace for the capture part. throw_exception, for instance, may reimplement the capture part, because it doesn't need to resolve.

...

// resolution

void stracktrace_resolve_frame( stacktrace_frame address, char function[], size_t fnsize, char file[], size_t filesize, size_t & line );

What if the user wants only the function name?

You can check for filesize < 2. Or for fnsize < 2.

As today - it is unsafe. We may assume the safety, but there's no guarantee. Moreover, I'm pretty sure that it is unsafe.

There are different levels of unsafety in practice, even though purists may claim that undefined is undefined and that's that. There's a whole spectrum from "almost always works" to "rarely works, if ever". If we're going to play the pedantry game, everything after a crash is already undefined behavior anyway. In practice, most important is to avoid the C/C++ runtime not just because this or that is not documented async-safe, but because a crash may be a symptom of random memory damage. Holding the loader lock is pretty much a guaranteed loss, apart from that, I'd estimate our chances as above average.

I'd rather take the boost/winapi path.

That's an option but, frankly, a separately compiled library is not that problematic, as long as you avoid autolinking it unless needed. That is, a simple capture should not attempt to link it. This is why I thought separating the capture and resolution into two headers worthwhile.