------- 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 <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
