cvs commit: src/sbin/fsck fsutil.h

[Bruce Evans]

On Sat, 27 Dec 2003, Andrey Chernov wrote:

> On Sat, Dec 27, 2003 at 05:54:03AM -0800, Bruce Evans wrote:
> >   Declare perror().  We define and use a home made version of perror(3)
> >   that can't simply be removed (although it has the same interface as
> >   perror(3)) since it is very different (it prints on stdout, doesn't
> >   always print the program name, and sometimes exits).  Declare it to
> >   get a reminder of this brokenness when WARNS is increased enough.
>
> If it is called from fsck only, maybe better way is to rename it to
> something like my_perror()?

It is called mainly from fsck_msdosfs (and fsck_ext2fs in NetBSD).
fsck_ffs doesn't use perror() or fsck/fsutil.c at all, at least in
FreeBSD.  It has its own fsutil.c and uses pfatal(), pwarn() and
printf().  These interfaces are confusing in different ways (pfatal()
is not always fatal ...).  perror() is only used once in fsck(8), and
this is just a bug in FreeBSD changes (fsck(8) otherwise uses only the
normal err() family).

This leaves fsck/fsutil.c only really used by fsck_msdosfs.  fsck_msdosfs
uses pfatal(), pwarn(), perror() and printf().  I think it shouldn't
use more or different interfaces than fsck_ffs, so it shouldn't use
perror() or fsck_ffs should use a better named and interaced version
of perror().  Perhaps the latter -- fsck_ffs rarely reports strerror(errno),
and fsck_msdosfs often reports this (via perror()) but it gives less
detail than fsck_ffs since there is no way to pass a non-literal string
to perror().

Bruce