[MPlayer-cvslog] r19959 - trunk/vidix/drivers/radeon_vid.c

[Rich Felker]

On Sun, Sep 24, 2006 at 08:36:06AM -0400, The Wanderer wrote:
> Rich Felker wrote:
> 
> >On Sat, Sep 23, 2006 at 06:46:08PM +0200, faust3 wrote:
> 
> >> #endif
> >>+  printf(RADEON_MSG" Video memory = %uMb\n",radeon_ram_size/0x100000);
> >> #ifdef WIN32
> >>+  //mapping large areas of video ram will fail on windows
> >
> >Change this to fprintf to stderr or better yet a proper log callback.
> >Having vidix drivers spam stdout is not acceptable.
> 
> Just for the record, this isn't the only such offense - there are
> presently 210 occurrences of '\bprintf' in vidix/drivers/*.c, 32 of them
> in that file.
> 
> That's out of ~1750 in the entirety of MPlayer, counting various
> included libraries (other than libav*); some of those are probably
> supposed to be there, but I've never been entirely clear on which files
> are considered separate enough to be allowed to use stdout directly.

NO LIBRARY is ever allowed to use stdout directly. Doing so is a bug.
Using stderr directly is closer to being acceptable but this is also a
very bad misdesign/offense. Libraries wishing to use debug output
should always do one of the following:

- use stderr (ugly but easy)
- let the application give the library a FILE* to use (also easy)
- provide a global callback function to use for reporting messages
- provide a local callback function in whatever context struct for
  reporting messages

The last option is always the correct one, but requires the most
repair work in existing poorly written libraries. The first two
options should be easy.

Rich