dlls/ntdll/file.c: Use FIXME_ONCE for quieter reports.

[Michael Stefaniuc]

Saulius Krasuckas wrote:
> * On Wed, 14 Jul 2010, Chris Robinson wrote:
>> * On Wednesday, July 14, 2010 5:02:59 pm Max TenEyck Woodbury wrote:
>>> 'FIXME's that contain no variable information are completely redundant 
>>> after their first report. After the first reminder, the additional 
>>> reports are just noise. They add no additional information in terms of 
>>> action required.
>> I wouldn't say that. Sometimes the simple knowledge that a FIXME is 
>> called a whole lot says enough on its own (eg, in WineD3D, you get a 
>> fixme when an sRGB reload occurs, because it's a performance drain; if 
>> this happens a lot, it can be taken as a source for performance issues). 
>> Sometimes knowing particular a fixme is triggered near to a crash or 
>> other behavioral anomaly can say a bit, too.
> 
> Although I stand for *_ONCE implementation, I agree with Chris.
> 
> And there might be some alternative: lets then implement it like a 
> 
>   FIXME_ONCE_PER(N)("a_debug_string");
> 
> Which could print something like a 
> 
>   "fixme:channel:a_debug_string [repeated N times]"
> 
> This would not oly still tell you approximate frequency of a FIXME, but it 
> also would require developer to know reasonable occurence quanta value (N) 
> or to tune it later.  This (for me) sounds like a way to know the code's 
> stochastic behaviour better!  Which would be a plus.
> 
>> If such fixmes were only printed once, it would be impossible to see 
>> this information without more in-depth testing that most users won't 
>> bother with. If the fixme is only printed once and the rest are TRACEs, 
>> it would still cause more work and a whole lot more noise (ie. all the 
>> other traces) in trying to spot it.
> 
> TRACE_ONCE probably could help in some cases too.  There I see another 
I fail to see how TRACE_ONCE could make any sense.
TRACE is used to trace the important parts of the code flow. Just
printing a TRACE once is less than helpful; it is waay better to not
print the TRACE at all.
Of course TRACE_ONCE should be defined for symmetry and preventing
somebody wasting time to send a patch with an implementation for it.
Too bad that Alexandre is too nice else that would be something like:

#define TRACE_ONCE      TRACE_ONCE_Misguided_developer_detected

bye
	michael

> constraint of *_ONCE functionality.  "Once" could be per block (eg. 
> for-loop), per wrapping function call, per process or even once per 
> thread's life.
> 
> Implementing all onces might be difficult, IMHO.  Though not all of 
> them could be necessary, probably.
> 
> 
> * On Thu, 15 Jul 2010, Dmitry Timoshkov wrote:
>> The patches which silense some FIXME's have been accepted as an 
>> exception. That covers the code which is unlikely to be fixed in near 
>> future, or the code nobody is working on.
> 
> Then at least replacement of these (ugly by their size, IMHO) 
> silence-blocks with a simple FIXME_ONCE seems rational.