I don't object to the proposed change.
There does remain a mysterious difference between
uwn_init_local_signal and unw_init _remote - namely, the setting of
c->validate=0 in one and not the other. It did lead to a difference
in outcome when I tried to use unw_init_remote to address my original
problem. I can imagine that someone, someday, will want a version of
initialization that sets c->validate to 1 for some reason. So a
little extensability makes sense.
Doug
Quoting Dave Watson <[email protected]>:
On 04/11/17 03:05 PM, Doug Moore wrote:
If there was to be a new man page for unw_init_local_signal, there
would be a reason to add another ‘see also’ to the page for
unw_init_remote. But no new page, so no need.
The modified unw_init_local page is good enough. It just wasn’t
what I was expecting.
So I've still been mulling this fix over. I'm tempted to change the
interface to:
unw_init_local_ex(unw_cursor_t, unw_context_t, int flags);
with a UNW_SIGNAL_FRAME flag - to try to future proof the interface a
bit. Or possibly even farther,
unw_init(unw_cursor_t, unw_addr_space_t, void* arg, int flags);
I think might work too.
Any objections or suggestions?
!DSPAM:10223,58ee4c4439341776378724!
_______________________________________________
Libunwind-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/libunwind-devel
