dlls/ntdll/file.c: Use FIXME_ONCE for quieter reports.
saulius2 at ar.fi.lt
Thu Jul 15 04:11:59 CDT 2010
* 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
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
constraint of *_ONCE functionality. "Once" could be per block (eg.
for-loop), per wrapping function call, per process or even once per
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.
More information about the wine-devel