Re: test-memchr crash

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Simon Josefsson on 6/13/2009 10:43 AM: >> Looks pretty much like one of the glibc memchr bugs that were recently fixed: >> > > I'm not sure, the machine where this fails runs glibc

Re: memchr and valgrind

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 6/15/2009 11:42 AM: > 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 le

Re: [PATCH] hash: declare some functions with the warn_unused_result attribute

Jim Meyering meyering.net> writes: > >> We should fix this, and decide whether shrinking the hash table when > >> deletion frees up a bucket is always possible, or else deal with memory > >> allocation failure here, too. > > > > Additionally, it looks like hash_rehash has a memory leak - if new_t

Re: gl_LIBSIGSEGV is broken

Sam Steingold wrote: > I just upgraded clisp to libsigsegv.m4 serial 4 Did you do a "make distclean; ./configure" after doing so? > and now LIBSIGSEGV is not set right: > > config.status: > > before: > $ grep -i sigsegv config.status > S["LIBSIGSEGV"]="-lsigsegv" > S["LTLIBSIGSEGV"]="-lsigsegv"

gl_LIBSIGSEGV is broken

I just upgraded clisp to libsigsegv.m4 serial 4 and now LIBSIGSEGV is not set right: config.status: before: $ grep -i sigsegv config.status S["LIBSIGSEGV"]="-lsigsegv" S["LTLIBSIGSEGV"]="-lsigsegv" D["HAVE_LIBSIGSEGV"]=" 1" D["HAVE_LIBSIGSEGV"]=" 1" after: $ grep -i sigsegv config.status S["LI

Re: abort() traceability

Simon Josefsson writes: > Sam Steingold writes: > >> Ben Pfaff wrote: >>> Bruno Haible writes: >>> What do the others think? Should we possibly extend stdlib.in.h so that abort() becomes a macro that produces a detailed error message, similar to what assert() does? >>> >>> Just c

Re: abort() traceability

Sam Steingold writes: > Ben Pfaff wrote: >> Bruno Haible writes: >> >>> What do the others think? Should we possibly extend stdlib.in.h so that >>> abort() becomes a macro that produces a detailed error message, similar to >>> what assert() does? >> >> Just changing abort() to assert(0) would im

Re: abort() traceability

Ben Pfaff wrote: Bruno Haible writes: What do the others think? Should we possibly extend stdlib.in.h so that abort() becomes a macro that produces a detailed error message, similar to what assert() does? Just changing abort() to assert(0) would improve the diagnostics significantly. Sound

memchr and valgrind

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: Er

Re: abort() traceability

Bruno Haible writes: > What do the others think? Should we possibly extend stdlib.in.h so that > abort() becomes a macro that produces a detailed error message, similar to > what assert() does? Just changing abort() to assert(0) would improve the diagnostics significantly. -- Ben Pfaff http://

Re: testsuite failures with current git master M4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 6/14/2009 12:50 AM: >>> Odd. All of these failures look like they are related to getopt; perhaps >>> there is some locale effect on the translation of the "`" in the getopt >>> strings when using glibc instead of gnulib

Re: abort() traceability

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 6/15/2009 2:08 AM: > What do the others think? Should we possibly extend stdlib.in.h so that > abort() becomes a macro that produces a detailed error message, similar to > what assert() does? Only if you name it something

[PATCH] link-follow: fix the "checking..." message to not mention trailing slash

FYP, just pushed: >From a933e8ee26612cb6857993cc921cc8e86161f488 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 14 Jun 2009 17:58:39 +0200 Subject: [PATCH] link-follow: fix the "checking..." message to not mention trailing slash * m4/link-follow.m4 (gl_AC_FUNC_LINK_FOLLOWS_SYMLINK): Thi

Re: abort() traceability

Sam Steingold wrote: > I am not saying that abort() is wrong. > I am saying that it must be accompanied by a meaningful message. OK, this is a different issue. > E.g, "Gnulib.drop_privileges_permanently: failed to drop privileges". > Or just "Error A23Z51DT97". > Then the user can google for the