[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libidn-1.21 failed test tst_idna2

From: Simon Josefsson
Subject: Re: libidn-1.21 failed test tst_idna2
Date: Mon, 25 Apr 2011 23:35:02 +0200
User-agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux)

Guido Trentalancia <address@hidden> writes:

>> > Since we are not testing the compiler here, could we not avoid the
>> > optimisation even when the user has explictly requested it ?
>> Valgrind will always test the compiler, since valgrind is checking the
>> binary code.  I'm not sure what you mean by the second part -- having
>> the code try to out-smart the person building the code rarely works
>> well.  Since this was strlen, I suspect that you will get the same
>> Valgrind error from almost any code.
>> > Using strnlen for example would lead to the same optimisation ?
>> Maybe, but it would be wrong to use strnlen here since the string is
>> guaranteed to be zero terminated.
> Overriding inherited CFLAGS with -O1 in tests/Makefile (eventually just
> for Valgrind tests) ?

First, the code that triggers Valgrind is in the library, not in the
self test.  Also, -O1 is not a generic compiler flag, it is specific to
gcc-like compilers and libidn works with other C compilers.  Finally,
there is simply no way of knowing what flags "inverts" flags passed by
the user in general.  If another user passes CFLAGS=--foo when building
Libidn, we may need to provide --bar when building libidn to "invert"
the effects of what the user requested.  Building with "-O1 --bar" just
to deal with situation like yours does not lead to a robust project.

You are better off using the default build parameters unless you know
what you are doing and are prepared to deal any issues.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]