Re: libidn-1.21 failed test tst_idna2

[Guido Trentalancia]

Hi Simon !

Thanks for your feedback.

On Mon, 2011-04-25 at 21:20 +0200, Simon Josefsson wrote:
> Guido Trentalancia <address@hidden> writes:
> 
> > Hello Simon !
> 
> Hi!  I re-added help-libidn on the cc list, please keep it so that
> others can learn from our discussion.
> 
> > Here is the output with -g added:
> ..
> > ==31295== Invalid read of size 4
> > ==31295==    at 0x402E46: idna_to_ascii_4z (idna.c:516)
> ...
> > ==31295==  Address 0x51ca8d8 is 8 bytes inside a block of size 10
> > alloc'd
> > ==31295==    at 0x4C282CD: malloc (vg_replace_malloc.c:236)
> > ==31295==    by 0x402F90: idna_to_ascii_4z (idna.c:528)
> ...
> > Using only -g in the CFLAGS and dropping all the rest (-O3 and
> > processor-specific optimisations) produces no errors.
> >
> > The problem is triggered by -O3, -O2 but not -O1.
> 
> That offending line contains a strlen.  I think this is just a matter of
> the compiler chosing a (too) optimized 'strlen' implementation that
> reads in chunks of 4 bytes even when the buffer is shorter.  In this
> case, it reads 4 + 4 + 4 bytes but the buffer is only 10 bytes

Since we are not testing the compiler here, could we not avoid the
optimisation even when the user has explictly requested it ?

Using strnlen for example would lead to the same optimisation ?

> It could be a compiler bug, but I suspect it is intentional to read even
> beyond the end of a buffer because it will be faster.  Thus, unless it
> is a compiler bug, you need to compile with the default compiler flags
> or specify --disable-valgrind-tests when building libidn.

At least you could add a note...?

> I hope this answers everything.
> 
> /Simon

Regards,

Guido