Re:A Defer Mechanism for C
by josephcsible on Monday December 14, 2020 @11:54AM
(#25419762)
Goto isn't nonlocal. You know you'll only every jump from them, and that you'll only ever jump to the specified label.
The specified label is what makes goto no-local. You need to check the whole codebase to find out where you'll land.
By your definition only [1] "come from" would be non-local.
FWIW, Normally the term "non local goto" is reserved for control transfer beyond the current activation frame. So C goto is strictly local, bit longjmp would be non-local.
Re:A Defer Mechanism for C
by josephcsible on Monday December 14, 2020 @02:46PM
(#25422243)
> the whole codebase
You can't goto out of a function, and you know there's exactly one such label inside it. If goto isn't local, then neither are function calls, since the function could be defined anywhere in the codebase.
>You can't goto out of a function
You can with a goto expression and a label address available - though the behavior is undefined in C, so bets are off.
And you can with longjump/setjump more explicitly.
Re:A Defer Mechanism for C
by josephcsible on Tuesday December 15, 2020 @08:48AM
(#25430229)
Are you talking about this? https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html It's a GNU extension, not part of standard C at all.
Plus, to handle the free or the leak if you had forgotten to free a resource at the exit point would also require to "know its lexical nesting up to top level".
Between goto and longjump and co, C has much worse non-local behavior than defer.