bug-gnulib
[Top][All Lists]
Advanced

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

Re: memcmp-tests module


From: Eric Blake
Subject: Re: memcmp-tests module
Date: Thu, 22 May 2008 14:07:14 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Simon Josefsson <simon <at> josefsson.org> writes:

> > It's good habit to include the tests from the autoconf macro also in the 
test
> > suite (to verify that the autoconf macro actually did its job). So I added 
this:
> >
> >
> > 2008-05-20  Bruno Haible  <bruno <at> clisp.org>
> >
> >     * tests/test-memcmp.c (main): Test also the sign of the result. Test
> >     against two known bugs; code taken from autoconf's AC_FUNC_MEMCMP.
> 
> Thanks!  FWIW, that updated self test works fine under mingw even
> without the gnulib memcmp (using the patch I sent earlier).

This test is tripping up a -Wall build on cygwin with gcc 3.4.4.  For the life 
of me, I can't find the location of the __attribute__((__nonnull__)) that is 
causing the warning, even when I ran through gcc -E; however, I think that it 
is a bug to attach the nonnull attribute to memcmp parameters (for the very 
reason that a compare of 0 bytes should not dereference the pointer, so passing 
NULL is not necessarily a bug).  But the warning is there, so I might as well 
work around it; I'm committing the patch below.

../../tests/test-memcmp.c: In function `main':
../../tests/test-memcmp.c:41: warning: null argument where non-null required 
(arg 1)
../../tests/test-memcmp.c:41: warning: null argument where non-null required 
(arg 2)
make[5]: *** [test-memcmp.o] Error 1


Meanwhile, I've been patching newlib (and thus cygwin) to have faster string.h 
operations.  For example, cygwin's strlen was using the x86 byte-wise 'repnz 
scasb' instruction as its inner loop, which is more than 3x slower on modern 
hardware than searching a word at a time (similar to our recent memchr.c 
algorithm improvements).  Likewise for cygwin's memcmp on unaligned memory 
(aligned memory did a word at a time, but unaligned was using the dirt 
slow 'repz cmpsb').  These gnulib tests have been invaluable in making sure I 
don't break things.  Unfortunately, I don't know of any sane way to test at 
configure time whether a replacement C implementation of memcmp is faster than 
the native implementation, to offer substituting in a rpl_memcmp for speed.


>From 6cc9690c07fa88ab7f9adc5cba9e9c56e84d90bb Mon Sep 17 00:00:00 2001
From: Eric Blake <address@hidden>
Date: Thu, 22 May 2008 07:57:37 -0600
Subject: [PATCH] Avoid gcc warning.

* tests/test-memcmp.c (main): Pass NULL indirectly.

Signed-off-by: Eric Blake <address@hidden>
---
 ChangeLog           |    5 +++++
 tests/test-memcmp.c |    4 +++-
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index dc0ade5..86aeadd 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2008-05-22  Eric Blake  <address@hidden>
+
+       Avoid gcc warning.
+       * tests/test-memcmp.c (main): Pass NULL indirectly.
+
 2008-05-21  Bruno Haible  <address@hidden>
 
        Add reference doc about ACLs.
diff --git a/tests/test-memcmp.c b/tests/test-memcmp.c
index 5c2ac29..50342cb 100644
--- a/tests/test-memcmp.c
+++ b/tests/test-memcmp.c
@@ -37,8 +37,10 @@
 int
 main (void)
 {
+  void *nil = NULL; /* Use to avoid gcc attribute((nonnull)) warnings.  */
+
   /* Test equal / not equal distinction.  */
-  ASSERT (memcmp (NULL, NULL, 0) == 0);
+  ASSERT (memcmp (nil, nil, 0) == 0);
   ASSERT (memcmp ("foo", "foobar", 2) == 0);
   ASSERT (memcmp ("foo", "foobar", 3) == 0);
   ASSERT (memcmp ("foo", "foobar", 4) != 0);
-- 
1.5.5.1








reply via email to

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