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:
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). 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.
Best, Erich
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.
- It should work with ANSI C compilers (the variadic macro problem)
- 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:
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.
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
-
Erich E. Hoover -
Michael Stefaniuc