CVS log for src/tests/usr.bin/xlint/lint1/Attic/msg_342.exp

Up to [cvs.NetBSD.org] / src / tests / usr.bin / xlint / lint1

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

tests/lint: remove .exp files, as they have become redundant

Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed.  The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.

tests/lint: make 'expect+-' comments stricter

Previously, the expectations from these comments were already satisfied
if the expectation occurred somewhere in the actual message from lint.
This meant that the prefix 'error:' or 'warning:' could be omitted from
the 'expect' comment.  These omissions were hard to see in a manual
review.  Now any omissions must be visually marked with '...'.

The test msg_342 now reports its messages properly as being in the file
msg_342.c, rather than msg_341.c.  This had been a copy-and-paste
mistake.

lint: split is_ctype_function into separate parts

This reduces the number of string comparisons for function names that
start with 'is' or 'to'.

The tests now cover function names that start with 'is' or 'to' but are
not one of the well-known functions from ctype.h.  This removes the '*'
in the output from gcov.

No functional change.

tests/lint: cover code in ckctype.c

lint: warn about for wrong type cast in argument to ctype.h functions

The argument to most of the functions from <ctype.h> "shall either be
representable as an 'unsigned char' or shall equal the value of the
macro EOF".

When confronted with the infamous warning 'array subscript has type
char', there are enough programmers who don't know the background of
that warning and thus fix it in a wrong way.  Neither GCC nor Clang
explain its warning to target these programmers.

Both GCC and Clang warn about 'array subscript has type char', but they
ignore the other requirements of the <ctype.h> functions, even though
these are in the C standard library.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94182
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177
https://stackoverflow.com/a/60696378