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

Subject: Re: [boost] [Stacktrace] review, please stop discussing non-Stacktrace issues
From: Peter Dimov (lists_at_[hidden])
Date: 2016-12-18 18:28:43

Antony Polukhin wrote:
> 2016-12-18 20:26 GMT+03:00 Peter Dimov <lists_at_[hidden]>:
> > 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.