RFC: "once" FIXME capability

[Michael Stefaniuc]

On 05/14/2014 12:05 AM, Erich E. Hoover wrote:
> While at LinuxTag Sebastian Lackner, Michael Müller, and I were
> chatting with Michael Stefaniuc and Anastasius Focht about the way we
> currently implement "one-time FIXME".  It was discussed that a more
> global approach to this was desired, but that it should have the
> following characteristics:
Thanks guys for attacking this problem.

> 1) It should work with ANSI C compilers (the variadic macro problem)
> 2) It should be something that we can disable with a debug channel
> (something AF would really appreciate that our current ad-hoc approach
> does not support)
> 3) It should be expandable to handling a "once per flag" capability
> 
> Toward that end the three of us have put together several proposed
> "once" implementations.  All three patch-sets are based on variations
> of the following trick to allow defining in-place static variables
> without any special compiler requirements:
> if(1) { \
>     static int __wine_debug_once = 0; \
>     int __wine_debug_once_temp = __wine_debug_once; \
>     if(!__wine_debug_once) __wine_debug_once = 1; \
>     if(__wine_debug_once_temp == 0) \
>         goto __WINE_LIMIT_LABEL(__LINE__); \
> } else __WINE_LIMIT_LABEL(__LINE__):
> 
> Here are the various approaches:
> 1) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_1.tgz
> This implementation is a macro (LIMIT_ONCE, LIMIT_FLAG_ONCE) that you
> would use to prefix a FIXME/WARN/etc.  The feature can be disabled by
> enabling the "+nolimit" WINEDEBUG option (patch 3).
I do not like this one. While it does look like todo_wine that makes it
not look like C. And IMHO the use of TRACE_ONCE / ERR_ONCE and maybe
even WARN_ONCE are questionable.

> 2) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_2.tgz
> This implementation builds onto the existing FIXME to add a FIXME_ONCE
> (and FIXME_FLAG_ONCE).  The feature can be disabled by enabling the
> "+nolimit" WINEDEBUG option (patch 4).
> 3) https://dl.dropboxusercontent.com/u/195059/wine/WineOnce_3.tgz
> This implementation builds onto the existing FIXME to add a FIXME_ONCE
> (and FIXME_FLAG_ONCE).  The feature can be disabled by enabling the
> "nolimit+<channel>" WINEDEBUG option (patch 4).  This version benefits
> from the ability to turn off limiting on a per-channel basis, which
> should make it easier to track down problems when an unrelated debug
> channel is also spamming the console.
> 
> We'd love to hear which approach everyone likes the most or any
> feedback you might have.
I don't mind if 2) or 3) is chosen. I debug too seldom to have an
opinion on it.

But I'm unsure about the use case for FIXME_FLAG_ONCE. The
implementation will need to have anyway code like
    if (flags & FLAG1)
	...
    if (flags & FLAG2)
	...
    if (flags & FLAG3)
	...

So that can be done from the start with a FIXME_ONCE for the noisy
flags.

bye
	michael