On Mon, 25 Nov 2024 at 07:35, Przemek Kitszel
<przemyslaw.kitszel@xxxxxxxxx> wrote:
>
> At one point I had a version that did:
> if (0)
> label: ;
> else
> for (....)
Well, that is impressively ugly.
> but it is goto-jumping back in the code
I'm not sure why you think *that* is a problem. It does look like it
avoids the dangling else issue, which seems to be the more immediate
problem.
(Of course, "immediate" is all very relative - the use-case that
triggered this is going away anyway and being replaced by a regular
'guard()').
That said, I have a "lovely" suggestion. Instead of the "if(0)+goto"
games, I think you can just do this:
#define scoped_guard(_name, args...) \
for (CLASS(_name, scope)(args), *_once = (void *)1; _once && \
(__guard_ptr(_name)(&scope) || !__is_cond_ptr(_name)); \
_once = NULL)
which avoids the whole UNIQUE_NAME on the label too.
Yeah, yeah, if somebody has nested uses of scoped_guard(), they will
have shadowing of the "_once" variable and extrawarn enables -Wshadow.
But dammit, that isn't actually an error, and I think -Wshadow is bad
for these situations. Nested temporary variables in macros shouldn't
warn. Oh well.
Is there a way to shut up -Wshadow on a per-variable basis? My
google-fu is too weak.
Did I test the above macro? Don't be silly. All my code works on first
try. Except when it doesn't.
Linus
