Re: CVS commit: src/usr.bin/man

[Roland Illig <roland.illig%gmx.de@localhost>]

Am 10.03.2022 um 22:48 schrieb David H. Gutteridge:
> > Module Name:    src
> > Committed By:   rillig
> > Date:           Tue Mar  8 23:13:05 UTC 2022
> >
> > Modified Files:
> >          src/usr.bin/man: man.c
> >
> > Log Message:
> > man: remove unused global variable 'instype' (since yesterday)
> >
> > No functional change.
> >
> >
> > To generate a diff of this commit:
> > cvs rdiff -u -r1.71 -r1.72 src/usr.bin/man/man.c
> >
> > Please note that diffs are not public domain; they are subject to the
> > copyright notices on the relevant files.
>
> Hi Roland,
>
> Hardly the most pressing concern for us to discuss, but, the reason I'd
> defined that global variable is because that's how NetBSD's "style"
> document shows it's done in its enum example. I didn't think that was
> necessary here, but took the "style" example literally.

Hi Dave,

I agree that taking the "style" example literally could lead to this
code, thank you for explaining how you arrived with this code.  In fact,
when I first saw your code I didn't realize that 'instype' was a
variable, I thought it would be a typedef name.  Only when I tried to
remove this unused name, the generated binary changed, which made me
cautious.

To avoid future misinterpretation, I fixed the enum example in
share/misc/style.

> As for the other change you made (enum vs. int), I guess that's just bad
> style on my part. I don't really work in C anymore, but when I did, in
> my context, we treated enum and int as being interchangable. Good to
> know.

I changed the parameter type from int to enum because this enables
stricter checks in the compilers and in lint.  They would report a
mismatch of enum types then.  The enum check in lint is not enabled by
default though, but still it is there (LINTFLAGS+= -e in the Makefile).

For usr.bin/man, there aren't many enum constants that could be
confused, but in other programs like usr.bin/make there are really many
of them, and 2 years ago there were even enum constants from different
types that used the same prefix "VAR_", which increased the confusion.
That's the reason that I prefer to be as specific with enum types as
possible.

Another benefit is that using 'enum' (or 'bool') instead of 'int'
communicates the purpose of the variable more precisely to human
readers, and I like this extra bit of precision.

Regards,
Roland