With the recent clarification on memchr behavior, it is conceivable that we
could trip false positives under valgrind when using memchr to find the
location of a known byte with an overestimated length (most frequently when
searching for a NUL). Any objections to applying this patch?
From: Eric Blake <e...@byu.net>
Date: Mon, 15 Jun 2009 11:04:21 -0600
Subject: [PATCH] memchr: add valgrind exception
* lib/memchr.valgrind: New file.
* modules/memchr (Files): Distribute it.
Signed-off-by: Eric Blake <e...@byu.net>
---
ChangeLog | 4 ++++
lib/memchr.valgrind | 14 ++++++++++++++
modules/memchr | 1 +
3 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 lib/memchr.valgrind
diff --git a/ChangeLog b/ChangeLog
index 81af4ec..b2492be 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
2009-06-15 Eric Blake <e...@byu.net>
+ memchr: add valgrind exception
+ * lib/memchr.valgrind: New file.
+ * modules/memchr (Files): Distribute it.
+
docs: memchr is no longer obsolete
* MODULES.html.sh: Move memchr from obsolete to string.h section.
diff --git a/lib/memchr.valgrind b/lib/memchr.valgrind
new file mode 100644
index 0000000..60f247e
--- /dev/null
+++ b/lib/memchr.valgrind
@@ -0,0 +1,14 @@
+# Suppress a valgrind message about use of uninitialized memory in memchr().
+# POSIX states that when the character is found, memchr must not read extra
+# bytes in an overestimated length (for example, where memchr is used to
+# implement strnlen). However, we use a safe word read to provide a speedup.
+{
+ memchr-value4
+ Memcheck:Value4
+ fun:rpl_memchr
+}
+{
+ memchr-value8
+ Memcheck:Value8
+ fun:rpl_memchr
+}
diff --git a/modules/memchr b/modules/memchr
index a77bec5..855c8db 100644
--- a/modules/memchr
+++ b/modules/memchr
@@ -3,6 +3,7 @@ memchr() function: scan memory for a byte.
Files:
lib/memchr.c
+lib/memchr.valgrind
m4/memchr.m4
m4/mmap-anon.m4
--
1.6.3.1
