[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
some lint bogosity
- To: tech_(_at_)_openbsd_(_dot_)_org
- Subject: some lint bogosity
- From: Marc Espie <espie_(_at_)_nerim_(_dot_)_net>
- Date: Mon, 3 Apr 2006 16:33:37 +0200
- Mail-followup-to: tech_(_at_)_openbsd_(_dot_)_org
- Reply-to: espie_(_at_)_nerim_(_dot_)_net
Tried -current lint on make.
lint -chabx -I/spare/src/usr.bin/make/obj -I/spare/src/usr.bin/make -DUSE_TIMESPEC -DHAS_BOOL_H -DHAS_PATHS_H -DHAS_EXTENDED_GETCWD -i /spare/src/usr.bin/make/arch.c
/spare/src/usr.bin/make/arch.c:349: warning: arg #2 converted to 'unsigned long' by prototype
/spare/src/usr.bin/make/arch.c:361: warning: arg #2 converted to 'unsigned long' by prototype
This is downright bogus.
This arg is a preprocessor constant (256). There is absolutely no harm in
converting this to an unsigned long.
- fixing this by adding a cast in the snprintf is stupid;
- fixing this by writing #define BMAKE_SIZE 256UL or
#define BMAKE_SIZE 256L is even more stupid, since it will change arithmetic
all over the place, and not just in the snprintf call...
I've looked at the `heuristics' used. This is ptconv in hflag mode spewing
out that warning.
This is not useful, this will show many more false positives that actual
Of course, as usual, this is a can of worms.
I think that, in order to be useful, lint ought to know a bit more about
constants and things.
- it should be able to assert that the current conversion is safe on a given
architecture, e.g., there is no issue at all with the conversion of the
constant 256 to an unsigned long value.
- it should even be able to check whether a conversion is always safe, e.g.,
knowing the rules for the C language, a size_t will always be wide enough
for storing 256 (portable mode).
Visit your host, monkey.org