the fact that all 4 of the wrappers call fprintf
is not, per se, an argument to replace the calls
with a nude fprintf. if one wishes to add logging,
it's a LOT easier to have wrappers in place than
to "just call printf". that's why you get weird
cruft trying to apply gray tape to STDIO to make
it do something odd - because one needs to catch
ALL the bloody printf calls.
you can argue the semantics of the routines are
sufficiently similar they can go from 4 to 2,
but just a wholesale replacement with fprintf
is NOT clearly an improvement.
some of it may well be cruft from an older time,
but some of it may be there for when the universe
isn't cooperating and you need to adjust.
frankly, in large systems i've written, NO code
outside a very limited library was allowed to
do anything that looked or smelled like it
would result in a system call. (this specifically
includes storage allocation, too) that has saved
many, many man-hours porting code or re-purposing it.
it also makes for self-contained debugging which
doesn't rely upon having a working debugger on
a new platform (or one you can't use - same thing).
this is especially useful when you aren't sure you
can trust your C compiler - like what is going on
right now in the Linux world! been there, done that,
it doth truly suck.
as for POSIX being some kind of portability guarantee,
uh, i guess i've been watching the sausage get made
far too long to buy that tale.
-mo
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers