Bruno Haible wrote: > Eric Blake wrote: >> > I don't think it is a bug. memchr could also be implemented by doing >> > a backwards search and still be conforming to ISO C99 and POSIX: >> >> The Austin Group disagrees with you. Here is the results from the meeting >> yesterday >> (https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=index.tpl&source=L&listname=austin-group-l&id=12144): > > Thanks for bringing up the issue. I'm glad that we can now expect as much > from memchr() as from strlen(). It's easier to fix the one or two buggy > implementations of memchr() out there [1][2][3] than to review all uses, in > strstr, vasnprintf, and many more. > >> But as there are systems in the wild with the broken implementation, we >> should probably start worrying about replacing the buggy memchr >> implementations. > > As a first step, let me add a test to test-memchr. Let's see whether we > get some reports about it. - Probably we also should undeprecate 'memchr', > so that its unit test gets included into m4, gettext, coreutils, etc.?
Thanks, yes. Along those lines, I've done the following in coreutils, though this causes no change in generated code. >From 25a6d1b88acec2d18eb23e4ab8abed3b84ca6455 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyer...@redhat.com> Date: Sun, 31 May 2009 15:18:16 +0200 Subject: [PATCH] build: no longer list gnulib's "memchr" module as obsolete * bootstrap.conf (obsolete_gnulib_modules): Remove memchr from the list, now that it fixes a problem in some modern C libraries. (gnulib_modules): Add it here. --- bootstrap.conf | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/bootstrap.conf b/bootstrap.conf index d34e908..6671027 100644 --- a/bootstrap.conf +++ b/bootstrap.conf @@ -27,7 +27,6 @@ avoided_gnulib_modules=' # but leave them in for now to minimize changes. obsolete_gnulib_modules=' atexit - memchr memcmp memcpy memmove @@ -141,6 +140,7 @@ gnulib_modules=" mbsalign mbswidth memcasecmp + memchr memcmp2 mempcpy memrchr -- 1.6.3.1.279.gd4bf4
