Hi Willy,
2013/5/27 Willy Tarreau <w...@1wt.eu>:
> Hi Joris,
>
> On Thu, May 23, 2013 at 01:53:19PM +0200, joris dedieu wrote:
>> Hello,
>>
>> I noticed several warings while compiling haproxy with clang (from
>> FreeBSD 9.1 base system).
>>
>> * 145 unused-value regarding mini-clist.h (LIST_ADD, LIST_ADDQ,
>> LIST_DEL) and standard.h (UBOUND
>>
>> src/haproxy.c:1206:4: warning: expression result unused [-Wunused-value]
>> LIST_DEL(&log->list);
>> ^~~~~~~~~~~~~~~~~~~~
>> include/common/mini-clist.h:117:95: note: expanded from macro 'LIST_DEL'
>> ...({ typeof(el) __ret = (el); (el)->n->p = (el)->p; (el)->p->n =
>> (el)->n; (__ret); })
>>
>> ^~~~~
>> The patch mute then by casting the return value to (void) as we can
>> expect further usage of those values.
>>
>> * 14 empty-body regarding a gcc warning fix
>>
>> src/haproxy.c:1532:73: warning: if statement has empty body [-Wempty-body]
>> if (write(pidfd, pidstr,
>> strlen(pidstr)) < 0) /* shut gcc warning */;
>>
>> ^
>> src/haproxy.c:1532:73: note: put the semicolon on a separate line to
>> silence this warning [-Wempty-body]
>>
>> The patch just apply clang recommendation " put the semicolon on a
>> separate line to silence this warning " (adding a hack to another).
>>
>>
>> As they are quite long, patches are attached.
>
> Thanks for doing this. But I'm really worried about the way code is
> progressively turning to because of those stupid compiler warnings.
> We're reaching a point where we uglify the code so much that it
> becomes confusing and error-prone. Soon it will be harder to code in
> C than in asm!
Well I preliminary did that to save my eyes from clang's blink color
printing. I of course agree that they definitively not need a real
fix.
>
> I think we'd rather work on silencing the compilers than altering
> the code. Having C code produce warning when a function returns an
> unused result is contrary to the initial principles of the C and
> contrary to the underlying implementation.
>
> So maybe we can find some "expect unused" attributes for the functions
> and macros, or maybe we can disable those stupid checks in the compiler's
> cflags.
So what about a conditional directive in the Makefile ? Something like
diff --git a/Makefile b/Makefile
index 5e12af8..89ca6a4 100644
--- a/Makefile
+++ b/Makefile
@@ -154,6 +154,10 @@ ADDLIB =
DEFINE =
SILENT_DEFINE =
+#### Compilers stupid warnings
+# Sometimes compilers emit warnings that don't need a fix. Mute them.
+COMPILER_CRAPS.clang = -Wno-unused-value
+COMPILER_CRAPS = $(COMPILER_CRAPS.$(CC))
#### CPU dependant optimizations
# Some CFLAGS are set by default depending on the target CPU. Those flags only
@@ -181,7 +185,7 @@ ARCH_FLAGS = $(ARCH_FLAGS.$(ARCH))
# These CFLAGS contain general optimization options, CPU-specific optimizations
# and debug flags. They may be overridden by some distributions which prefer to
# set all of them at once instead of playing with the CPU and DEBUG variables.
-CFLAGS = $(ARCH_FLAGS) $(CPU_CFLAGS) $(DEBUG_CFLAGS) $(SPEC_CFLAGS)
+CFLAGS = $(ARCH_FLAGS) $(CPU_CFLAGS) $(DEBUG_CFLAGS) $(SPEC_CFLAGS)
$(COMPILER_CRAPS)
>
> Anyway, I'm really tired at fighting with this compilers!
>
> So if you can find portable solutions which disable those annoying
> stupid warnings, I'm all ears open !
I know one unfortunately , but it's called autoconf :(
Joris
>
> Willy
>
