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

[Reynaldo H. Verdejo Pinochet]

On Fri, Oct 15, 2004 at 10:15:10PM -0400, The Wanderer wrote:
> Reynaldo H. Verdejo Pinochet wrote:
> 
> >On Fri, Oct 15, 2004 at 09:41:25PM -0400, The Wanderer wrote:
> >
> >>If necessary, if no one more competent (or at least more familiar
> >>with the code) starts going through and correcting the MSG?_FIXMEs,
> >>I may start doing that myself after the printfs are all gone. In
> >>the meantime, however, in the absence of more pressure to do
> >>otherwise I think I'll stick with my current policy.
> >
> >been you an I the ppl doing most of the late printf/mp_msg work,
> >maybe we can decide on a common policy and let the big brothers talk,
> >
> I can agree with this in principle, but in practice it becomes more
> difficult.
yep, but adding a patch that will need a future 'patch' to be complete
is not *that* nice.
> 
> >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*....)
> 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.
> ERR and WARN are more difficult to distinguis h, because the things which
> are most obviously ERRors and not WARNings fall under the heading of
> FATAL. I've used MSGL_ERR at least once so far, when it was blatantly
> obvious that that level was correct - but as I said, I'm reluctant to
> start using that as policy, because there may be times when I think of a
> thing as being blatantly obvious but I'm wrong. When I'm doing it only
> as the exception to a rule, that's not likely to happen - but if I start
> doing it as *part* of a rule, I know from experience in other areas that
> I can very easily go overboard.
This is the reason why this patches need reviewing, and are
applied by NONE of us. (wanderer / reynaldo)
> 
> 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.

Best regards

  Reynaldo
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20041015/9a8d20cf/attachment.pgp>