Re: libidn-1.21 failed test tst_idna2

[Simon Josefsson]

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.

/Simon