[MPlayer-dev-eng] [PATCH] printf --> mp_msg transition (multiple files)

[The Wanderer]

Reynaldo H. Verdejo Pinochet wrote:

> On Fri, Oct 15, 2004 at 10:15:10PM -0400, The Wanderer wrote:
> 
>> Reynaldo H. Verdejo Pinochet wrote:

>>> been this the place to do so, i throw out my first:
>>> 
>>> 1.- Facing the need of replacing printf's with mp_mgs's, if the
>>> message states a clear error/warning, correct MSGL's should be
>>> used _not_ MSGL_FIXME.
>> 
>> I can see the sense of this, but the difficulty is, how to decide
>> whether something is a WARNing, an ERRor, or outright FATAL? (Or
>> for that matter, merely INFOrmative, or suchlike?)
> 
> there are things that should be errors, ie: 'out of memmory', we can
> think off others without to much brainstorming, there is ppl here who
> can help us to build a list of the most clearer ones, if one can not
> understand the code enough to choose a correct MSGL, then we must
> rely on the original printf information, if it says 'error' then, it
> is an error, printf/mp_msg patches should be reviewed at last by the
> code maintainer of the to-be-patched file, so i cant think of a
> problem here. (i know this may not be the case with a bunch of
> *maintainers*....)

The original idea of MSG?_FIXME was to make it easy for the maintainer
to find the problematic code and correct it, without requiring others to
leave the printf issue unfixed in the meantime. If after files have been
changed their maintainers don't go back and look at them then it might
eventually be appropriate to do a little judicious nagging, but if we
wait for the maintainers to explain what should be which MSG? in even
most cases much less every case then we'll be waiting forever for each
patch to get applied.

(I'm sorry, the above is not as coherent or sensical as I'd like it to
be. I'm not quite properly awake.)

>> FATAL should, IMO, be used only for things which exit immediately
>> after printing the message, but there may be some things which
>> *should* exit promptly but don't - in which case the correct thing
>> to do is not use a lower MSGL (ERR in this case), but to add the
>> exiting code.
> 
> when you find something like this, the most important thing will be
> to report/fix the bug, we can have an especial MSGT for this, 
> clearily stating that the code should be fixed.

Yes, yes, from that direction what to do is obvious. I meant it the
other way around; when we see that it exits immediately after a message,
we can tell that it should be MSGL_FATAL - but if it doesn't exit, but
should, we won't be able to tell that it should, and by using another
non-FIXME message level we'll be simply compounding the problem.

>> If you have any ways to handle these sorts of issues, I'd be glad
>> to hear of them, but in the meantime...
> 
> yhea, go ahead, not that i'm stoping you or something ;) but i think
> this is an issue to discuss.

It is, at the very least, something to keep in mind. I'll pay a little
more attention to this issue in making future patches, in light of
something I'd forgotten about from early discussion of the effort; in
the meantime, could someone with the authority to say one way or the
other tell me whether this patch is fine as it is, or I ought to make
the suggested MSGL changes and resubmit?

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

A government exists to serve its citizens, not to control them.