CVS log for src/tests/usr.bin/xlint/lint1/Attic/d_constant_conv2.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'.

lint: in C99 mode, do not warn about non-prototype conversions

Message 259 is "argument #%d is converted from '%s' to '%s' due to
prototype", and it is intended to warn about compatibility between
traditional C where functions had no prototypes and standard C where
functions have prototypes.

Running lint in C99 mode is further away from traditional C than running
lint in C90 mode, so that warning doesn't make sense for C99.  There are
still some inconsistencies in the 5 language version modes that lint
offers:

	-t		for traditional C
	(no option)	for migrating traditional C to C90
	-s		for C90 code
	-S		for C99 code
	-Ac11		for C11 code

By disabling warning 259 in C99 mode, a typical NetBSD build produces
14.500 fewer warnings than before, of about 100.000 total.

Message 259 overlaps with message 298 "conversion from '%s' to '%s' may
lose accuracy, arg #%d", and in some cases of potentially lossy
conversions, lint now produces none of these messages.  In some other
cases, these warnings were reported redundantly.  The cases where
message 298 makes sense will be added back later, as needed.

tests/lint: expect complete messages in feature tests

Previously, the tests contained many comments like /* expect: 123 */,
which were useless to a casual reader since nobody is expected to learn
lint's message IDs by heart.  Replace these with the complete
diagnostics, to show what lint is complaining about.

The tests named msg_*.c have been left unmodified since they mention the
full message text in their header comment.

No functional change.

lint: add back "due to prototype" to message 259

That message is only supposed to warn about compatibility to traditional
C, in case the function should ever be compiled without its prototype
being in effect.  All other type checks are supposed to be in another
function, as documented, but that type check misses to report a few
error-prone type combinations (long to char, long to int).

30 years after the introduction of prototypes with C90, almost all
existing code uses prototypes.  The warning has thus lost most of its
usefulness and can rather be confusing since a conversion from 'char' to
'long' is not problematic with prototypes in action, and the probability
of the code being backported to a pre-C90 compiler is diminishingly
small.

The words "due to prototype" now serve as a hint again.  The proper fix
could be to suppress this warning in C99 mode since that's far enough
from traditional C.

lint: add common header for all tests

For those tests that didn't use GCC-style line markers such as "# 2",
the line numbers of the diagnostics stay the same.  This is purely
conincidental.  Before, the 3 lines came from lint's built-in
definitions (see 'builtins' in main1.c), and line number counting
continued as if nothing had happened, making the first line of the
actual file line 4.  These 3 built-in lines are now replaced with 3
lines of file header.

lint: reword message 259 about function argument conversion

The words "due to prototype" are an anachronism from the 1990s.
Nowadays every function is defined using a prototype, which makes these
words redundant.

lint: make warning about function argument conversion more detailed

For every conversion it is useful to know both the source and the target
type since these are not always obvious from the code.

The only surprise is the warning in d_gcc_extension.  The conversion
there is from 'double' to 'long double', which is a lossless conversion.
This may be a bug in lint.

lint: for tests with output, ensure that the output matches