------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1145
--- Comment #1 from Phil Pennock <pdp@???> 2011-09-05 20:55:42 ---
Clang generated many more warnings until
http://git.exim.org/exim.git/commit/1ba28e2b955b005ce4825fec792df17f75a8de1e
and
http://git.exim.org/exim.git/commit/b3c261f710276f28ea23bf86dddacdf5fb4612b4
which were part of Exim 4.76.
(I've been limited by the available version of Clang for the platform/release
running on my main dev box, no 2.9 support.)
The valgrind stuff, I've ignored. Valgrind plays funny buggers with low-level
details, I expect any decent diagnostic compiler to complain vociferously about
it.
The printf %n complaints are advisory but unwarranted. %n modifies a parameter
and that's where the danger comes in, but when you _want_ this behaviour, it's
very useful and absolutely safe. If Clang were even better at analysis, it
would detect that it's been given a pointer for that parameter, that the
invocation is safe, and it wouldn't complain.
The array indexing issues for args[1] items are complaints about inline memory
allocation, where you have a header and then a list of "some number of" items.
If we wrote in C99, we would just declare args[] because C99 has flexible array
members. We will not be updating Exim to C99 because we still support many
older compilers, so this warning is spurious where it occurs in Exim (when I
checked).
That leaves the warnings below; the mime.c needs further investigation to
decide what was intended, to be sure that the noop is harmless. The four
printf/debug_printf complaints in exim.c all refer to diagnostic output and
tracking types whose sizes are awkward to reliably portably. In every case,
we're taking a broader format spec than the data type itself, so the worst that
could happen is that we'd end up printing a weird number in diagnostics.
I've a very vague recollection that the size_counter issue was there before my
cleanup sweep before, and that I left it pending further investigation.
-Phil
mime.c:344:48: warning: comparison of unsigned expression < 0 is always false
[-Wtautological-compare]
if (fclose(decode_file) != 0 || size_counter < 0)
~~~~~~~~~~~~ ^ ~
exim.c:337:35: warning: conversion specifies type 'unsigned long' but the
argument has type 'time_t' (aka 'int') [-Wformat]
debug_printf("tick check: %lu.%06lu %lu.%06lu\n",
~~^
%d
exim.c:337:45: warning: conversion specifies type 'unsigned long' but the
argument has type 'time_t' (aka 'int') [-Wformat]
debug_printf("tick check: %lu.%06lu %lu.%06lu\n",
~~^
%d
exim.c:339:31: warning: conversion specifies type 'unsigned long' but the
argument has type 'time_t' (aka 'int') [-Wformat]
debug_printf("waiting %lu.%06lu\n", itval.it_value.tv_sec,
~~^ ~~~~~~~~~~~~~~~~~~~~~
%d
exim.c:913:33: warning: conversion specifies type 'unsigned long' but the
argument has type 'unsigned int' [-Wformat]
fprintf(f, "Size of off_t: " SIZE_T_FMT "\n", sizeof(off_t));
^ ~~~~~~~~~~~~~
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
