Re: CVS commit: src/lib/libc

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sat, 8 Jun 2024 11:51:43 +0200
> From: Roland Illig <roland.illig%gmx.de@localhost>
> 
> Am 07.06.2024 um 22:50 schrieb Taylor R Campbell:
> > libc: Pacify lint on aarch64.
> >
> > +++ src/lib/libc/stdlib/Makefile.inc	Fri Jun  7 20:50:13 2024
> > +# lint(1) spuriously complains about `*s == CHAR_MAX' even though *s
> > +# has type char.
> > +LINTFLAGS.strfmon.c += -X 230
> 
> I guess the "spuriously" here means "on platforms where 'char' is
> unsigned", not "sometimes on the same platform, unpredictably".

Correct.

> Lint does not warn if the constant is defined as a character constant,
> so '\xff' instead of 0xff would work, but I don't know what else would
> be affected if the definition of CHAR_MAX were changed.

Might work but I'm reluctant to try without extensive testing on a lot
of compilers in a lot of environments.  E.g., does that work in C89?

> Ideally, lint would not warn about this expression, but since lint only
> looks at the preprocessed translation unit, it cannot know that the 0xff
> comes from CHAR_MAX and thus is fine.  Practically, suppressing the
> warning in this particular case makes sense.
> 
> Any ideas how to resolve this situation?

No brilliant ideas, sorry, other than to teach lint to track
provenance of constants through macro expansion.  That's why I just
disabled the warning for this case.