Re: test-intprops.c: many new warnings

Paul Eggert wrote: > On 05/24/11 12:36, Jim Meyering wrote: >> "make check" was inundated with new warnings. >> Nearly 500 lines worth. > > Thanks, I fixed those by pushing the following two patches: Those look fine and work for me. Thanks!

Re: test-intprops.c: many new warnings

On 05/24/2011 05:50 PM, Paul Eggert wrote: > +++ b/tests/test-intprops.c > @@ -16,6 +16,12 @@ > > /* Written by Paul Eggert. */ > > +/* Tell gcc not to warn about the many (X < 0) expressions that > + the overflow macros expand to. */ > +#if (__GNUC__ == 4 && 3 <= __GNUC_MINOR__) || 4 < __

Re: test-intprops.c: many new warnings

On 05/24/11 12:36, Jim Meyering wrote: > "make check" was inundated with new warnings. > Nearly 500 lines worth. Thanks, I fixed those by pushing the following two patches: --- ChangeLog |9 + lib/intprops.h |8 2 files changed, 13 insertions(+), 4 deletions(-) di

[PATCH] docs: document recently fixed glibc printf bug

Document it as a known bug, but one where we don't provide a workaround since programmers are unlikely to hit it in practice. * doc/posix-functions/fprintf.texi (fprintf): Document it. * doc/posix-functions/printf.texi (printf): Likewise. * doc/posix-functions/vfprintf.texi (vfprintf): Likewise. *

[PATCH 2/3] yesno-tests: convert to init.sh

* modules/yesno-tests (Files): Add init.sh. * tests/test-yesno.sh: Use it. Signed-off-by: Eric Blake --- ChangeLog |4 +++ modules/yesno-tests |1 + tests/test-yesno.sh | 56 +- 3 files changed, 29 insertions(+), 32 deletions(-)

[PATCH 3/3] closein-tests: convert to init.sh

* modules/closein-tests (Files): Add init.sh * tests/test-closein.sh Use it. Signed-off-by: Eric Blake --- ChangeLog |4 modules/closein-tests |1 + tests/test-closein.sh | 38 -- 3 files changed, 21 insertions(+), 22 deletions(-) d

[PATCH 1/3] atexit-tests: ensure reliable exit status

This was the only remaining init.sh client that didn't properly use the 'Exit' function. * tests/test-atexit.sh: Prefer 'Exit' over 'exit'. Reported by Bruno Haible. Signed-off-by: Eric Blake --- > Shouldn't this patch also be applied to tests/test-atexit.sh? > It's the first test that uses ini

Re: fprintf failures on read-only streams

Hi Eric, > Just last week, glibc fixed a bug where vfprintf failed to set ferror() > when returning EOF due to an attempt to output to a read-only stream: > > http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=aec84f5395 > > Should we update fprintf-posix and friends to detect this bug and wo

Re: request: pointer to the docs in the module file

Sam Steingold wrote: > >> How do I find out where a module is documented? Look at the gnulib manual TOC If it's not a ISO C / POSIX or GNU substitute module, then take a look at the chapter "Particular Modules". > I usually cannot

Re: [PATCH 3/3] perror: work around FreeBSD bug

Eric Blake wrote: > I'm still seeing perror failures on at least > AIX and Irix, due to strerror_r but not perror being replaced. I'm not > quite sure of the right m4 fix to make, but hopefully I can fix this > soon (first, though, I plan on completing my strerror_r work). I'm applying one of the

Re: [PATCH 2/2] perror: avoid spurious test failure on HP-UX

Eric Blake wrote: > The next-to-last command in this test has non-zero status. Even > though 'exit 0' is supposed to ignore prior status, HP-UX /bin/sh > favors the prior status if an exit trap is installed. > > * tests/test-perror.sh: Use Exit to avoid wrong exit status. Shouldn't this patch al

Re: [PATCH] getopt: for ambiguous options, enumerate the possibilities.

Hi James, Thanks for having dealt with the second and third point of . What about the first one? Can you just add the reference to in the ChangeLog entry? And also, when you t

Re: getloadavg is broken

On 05/24/2011 03:57 PM, Bruno Haible wrote: > Sam Steingold wrote: >> Unless I remove the offending line (see the appended patch), configure >> fails with "../src/src/gllib/getloadavg.c is missing" message. >> apparently $srcdir is "../src" and $1=$gl_source_base="src/gllib" which >> cannot be comb

Re: getloadavg is broken

Sam Steingold wrote: > Unless I remove the offending line (see the appended patch), configure > fails with "../src/src/gllib/getloadavg.c is missing" message. > apparently $srcdir is "../src" and $1=$gl_source_base="src/gllib" which > cannot be combined into anything sensible. This code was meant

Re: strerror vs. threads

On 05/24/2011 03:30 PM, Simon Josefsson wrote: > Maybe there could be a strerror_r-gnu and strerror_r-posix choice? Or a > strerror_r-posixlean to just do the minimum required by POSIX. I think a strerror_r-gnu module might be nice, especially now that I've posted a patch series that decouples st

[PATCH] getopt: for ambiguous options, enumerate the possibilities.

* lib/getopt.c (_getopt_internal_r): Merge glibc change printing the ambiguous options when an ambiguous prefix is given. This was glibc Buganizer wishlist bug 7101. --- ChangeLog|7 lib/getopt.c | 87 ++ 2 files changed, 76 in

Re: new files imported without new modules added

On 05/24/2011 03:39 PM, Bruno Haible wrote: > 1) In code that ends up in lisp.run (e.g. errunix.d). This executable has > the option to use multiple threads. Therefore strerror_r should be > used instead of strerror(), because - as Eric explained - when you > call strerror(EACCES)

[PATCH 2/2] strerror: drop strerror_r dependency

* modules/strerror-override: New module. * lib/strerror_r.c (strerror_r): Move gnulib replacement strings... * lib/strerror-override.c (strerror_override): ...to new file. * lib/strerror-override.h: Add prototype. * lib/strerror-impl.h: Delete. * lib/strerror.c (strerror): New implementation. * mod

[PATCH 1/2] perror: call strerror_r directly

No need to make a wrapper that burns static storage when we can just use stack storage. * modules/perror (Files): Drop strerror-impl.h. * lib/perror.c (perror): Use our own stack buffer, rather than calling a wrapper that uses static storage. * doc/posix-functions/perror.texi (perror): Document a

Re: new files imported without new modules added

Sam Steingold wrote: > > strerror and perror now depend on strerror_r ... > > I do _not_ want strerror_r. Actually you do want strerror_r in clisp, not strerror. There are two kinds of uses of strerror() in clisp: 1) In code that ends up in lisp.run (e.g. errunix.d). This executable has t

Re: strerror vs. threads

Eric Blake writes: > On 05/24/2011 12:52 PM, Simon Josefsson wrote: >>> POSIX explicitly allows strerror to use a static buffer, and that's >>> _exactly_ what gnulib's implementation does on out-of-range input. >>> Which means that "Unknown error (-1)" of thread 1 and "Unknown error >>> (-2)" of

getloadavg is broken

Unless I remove the offending line (see the appended patch), configure fails with "../src/src/gllib/getloadavg.c is missing" message. apparently $srcdir is "../src" and $1=$gl_source_base="src/gllib" which cannot be combined into anything sensible. no other module does such a check, so it is not cl

[PATCH] strerror_r: fix missing header

snprintf is not guaranteed to work without a declaration. * lib/strerror_r.c: Avoid compiler warning about snprintf. Signed-off-by: Eric Blake --- ChangeLog|3 +++ lib/strerror_r.c |1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 2

Re: disabling multithreading

Eric Blake wrote: > for a single-threaded application, having strerror_r call strerror without > locking is just fine, so the mere use of just the 'strerror' module > should not drag in locking. strerror_r only needs locking if it is used > in a multi-threaded application. The first step in this

[PATCH 3/3] strerror_r: fix AIX test failures

Already documented as an AIX limitation. * lib/strerror_r.c (strerror_r): Convert silent truncation to ERANGE failure. Signed-off-by: Eric Blake --- ChangeLog|4 lib/strerror_r.c | 20 +++- 2 files changed, 23 insertions(+), 1 deletions(-) diff --git a/Change

[PATCH 1/3] strerror_r: enforce POSIX recommendations

POSIX recommends (but does not require) that strerror_r populate buf even on error. But since we guarantee this behavior for strerror, we might as well also guarantee it for strerror_r. * lib/strerror_r.c (safe_copy): New helper method. (strerror_r): Guarantee a non-empty string. * tests/test-str

[PATCH 2/3] strerror_r: fix Solaris test failures

Solaris 10 populates buf on EINVAL, but not on ERANGE. * lib/strerror_r.c (strerror_r): Partially populate buf on ERANGE failures. * doc/posix-functions/strerror_r.texi (strerror_r): Document this. Signed-off-by: Eric Blake --- ChangeLog |5 + doc/posix-functio

Re: strerror vs. threads

Having had to deal with too many dependencies when using gnulib in GNU Emacs, I can sympathize with Sam Steingold: it'd be nicer to not pull in lock.c, lock.h, threadlib.c merely because an application wants to use strerror. For example, I can't see Emacs using the strerror module if this problem

test-intprops.c: many new warnings

Still trying the latest from gnulib via coreutils, "make check" was inundated with new warnings. Nearly 500 lines worth. Of course, I could simply turn off the warnings and/or -Werror when building in gnulib-tests/, but I'd rather not. I'll defer "upgrading to the latest" for now ;-) ... Making c

Re: strerror vs. threads [was: new files imported without new modules added]

On 05/24/2011 01:27 PM, Sam Steingold wrote: >> * Eric Blake [2011-05-24 12:24:34 -0600]: >> >> strerror(-1) in thread 1 >> strerror(-2) in thread 2 > > thanks for the explanation. > > My further questions are: > you are not using the standard win32 FormatMessage() function. > how do you hangle

[PATCH] test-perror2.c: avoid warning about unused variable

Trying out the latest from gnulib via coreutils, I saw this new warning/failure: ... Making check in gnulib-tests ... test-perror2.c: In function 'main': test-perror2.c:42:9: error: unused variable 'fp' [-Werror=unused-variable] cc1: all warnings being treated as errors make[5]: ***

Re: strerror vs. threads [was: new files imported without new modules added]

> * Eric Blake [2011-05-24 12:24:34 -0600]: > > strerror(-1) in thread 1 > strerror(-2) in thread 2 thanks for the explanation. My further questions are: you are not using the standard win32 FormatMessage() function. how do you hangle the gazillion windows error messages? (same goes for system-s

Re: [PATCH 3/3] perror: work around FreeBSD bug

On 05/20/2011 11:59 AM, Eric Blake wrote: > POSIX requires that 'errno = 0; perror ("")' print the same message > as strerror(0), but this failed if we were replacing strerror to work > around the FreeBSD bug of treating 0 as a failure. > > * m4/perror.m4 (gl_FUNC_PERROR): Also replace perror if s

fprintf failures on read-only streams

Just last week, glibc fixed a bug where vfprintf failed to set ferror() when returning EOF due to an attempt to output to a read-only stream: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=aec84f5395 Should we update fprintf-posix and friends to detect this bug and work around it on older

Re: new files imported without new modules added

On 05/24/2011 10:32 AM, Sam Steingold wrote: > I think this is wrong. I do not want strerror_r. I did not ask for it > and there is no need for it in any module I asked for. Umm, but there is - the strerror module needs it, to guarantee that it outputs the same replacement errno strings, without c

Re: strerror vs. threads

On 05/24/2011 12:52 PM, Simon Josefsson wrote: >> POSIX explicitly allows strerror to use a static buffer, and that's >> _exactly_ what gnulib's implementation does on out-of-range input. >> Which means that "Unknown error (-1)" of thread 1 and "Unknown error >> (-2)" of thread 2 are calling sprint

Re: strerror vs. threads [was: new files imported without new modules added]

Eric Blake writes: > On 05/24/2011 12:06 PM, Sam Steingold wrote: >>> * Eric Blake [2011-05-24 10:54:20 -0600]: >>> >>> Are you multi-threaded? Then you are suffering from a data race. >> >> I am sorry, I am afraid I am out of my depth. >> Why is this function "suffering from a data race"? >>

strerror vs. threads [was: new files imported without new modules added]

On 05/24/2011 12:06 PM, Sam Steingold wrote: >> * Eric Blake [2011-05-24 10:54:20 -0600]: >> >> Are you multi-threaded? Then you are suffering from a data race. > > I am sorry, I am afraid I am out of my depth. > Why is this function "suffering from a data race"? > > const char *strerror (int e

Re: new files imported without new modules added

> * Eric Blake [2011-05-24 10:54:20 -0600]: > > Are you multi-threaded? Then you are suffering from a data race. I am sorry, I am afraid I am out of my depth. Why is this function "suffering from a data race"? const char *strerror (int e) { switch (e) { case EINPROGRESS: return "Operation

Re: request: pointer to the docs in the module file

> * Eric Blake [2011-05-24 11:37:40 -0600]: > On 05/24/2011 11:26 AM, Sam Steingold wrote: >> How do I find out where a module is documented? >> E.g., when I discovered the getloadavg module, I had to do >> find gnulib/ -name getload\* >> to find gnulib/doc/glibc-functions/getloadavg.texi. > > If

Re: sed hangs on solaris

> * Paul Eggert [2011-05-03 13:52:21 -0700]: > > On 05/03/11 13:26, Sam Steingold wrote: >> note that some pipelines appear to succeed before the hanging: > > Yes. If it is a kernel bug, quite possibly it's timing-dependent, > and I wouldn't be surprised if it's not that common. isn't gnulib's r

Re: request: pointer to the docs in the module file

On 05/24/2011 11:26 AM, Sam Steingold wrote: > Hi, > > How do I find out where a module is documented? > E.g., when I discovered the getloadavg module, I had to do > find gnulib/ -name getload\* > to find gnulib/doc/glibc-functions/getloadavg.texi. If it is a POSIX function, it is documented in g

request: pointer to the docs in the module file

Hi, How do I find out where a module is documented? E.g., when I discovered the getloadavg module, I had to do find gnulib/ -name getload\* to find gnulib/doc/glibc-functions/getloadavg.texi. It would be nice if there were a pointer in gnulib/modules/getloadavg, preferably a URL with the up-to-dat

Re: new files imported without new modules added

On 05/24/2011 10:45 AM, Sam Steingold wrote: >> * Eric Blake [2011-05-24 10:32:16 -0600]: >> >>> I do _not_ want strerror_r. >> >> Why not? > > because I copy away the strerror return value right away. Are you multi-threaded? Then you are suffering from a data race. Are you single threaded? T

Re: new files imported without new modules added

> * Eric Blake [2011-05-24 10:32:16 -0600]: > >> I do _not_ want strerror_r. > > Why not? because I copy away the strerror return value right away. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://mideasttruth.com http://thereligionofpeace.com http

Re: new files imported without new modules added

> * Eric Blake [2011-05-24 10:21:16 -0600]: > On 05/24/2011 10:18 AM, Eric Blake wrote: >> On 05/24/2011 10:12 AM, Sam Steingold wrote: >>> I updated gnulib and found that it now wants to add these files to >>> CLISP: >>> >>> src/gllib/glthread/lock.c >>> src/gllib/glthread/lock.h >>> src/gllib/gl

Re: new files imported without new modules added

On 05/24/2011 10:27 AM, Sam Steingold wrote: >> * Eric Blake [2011-05-24 10:18:05 -0600]: >> On 05/24/2011 10:12 AM, Sam Steingold wrote: >>> I updated gnulib and found that it now wants to add these files to >>> CLISP: >>> >>> src/gllib/glthread/lock.c >>> src/gllib/glthread/lock.h >>> src/gllib/

Re: new files imported without new modules added

> * Eric Blake [2011-05-24 10:18:05 -0600]: > On 05/24/2011 10:12 AM, Sam Steingold wrote: >> I updated gnulib and found that it now wants to add these files to >> CLISP: >> >> src/gllib/glthread/lock.c >> src/gllib/glthread/lock.h >> src/gllib/glthread/threadlib.c >> src/gllib/strerror-impl.h >>

Re: [PATCH] utimensat: do not reference an out-of-scope buffer

On 05/24/2011 10:25 AM, Jim Meyering wrote: > Another coverity-spotted bug. > Eric, ok to push? > >>From 6dc42e2d25df9c84b335062bad9beb0a7319647b Mon Sep 17 00:00:00 2001 > From: Jim Meyering > Date: Tue, 24 May 2011 18:24:24 +0200 > Subject: [PATCH] utimensat: do not reference an out-of-scope bu

Re: [PATCH 1/2] tests: fix logic bug in init.sh

Eric Blake wrote: > If the shell test loop first finds a marginal then a good shell, the > variable $gl_set_x_corrupts_stderr is still set to true and needlessly > drops $VERBOSE logging. > > * tests/init.sh: (gl_set_x_corrupts_stderr_): Clear for successful > shell. Perfect. Thanks!

[PATCH] utimensat: do not reference an out-of-scope buffer

Another coverity-spotted bug. Eric, ok to push? >From 6dc42e2d25df9c84b335062bad9beb0a7319647b Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 24 May 2011 18:24:24 +0200 Subject: [PATCH] utimensat: do not reference an out-of-scope buffer Otherwise, with __linux__ defined, "times" would po

[PATCH 1/2] tests: fix logic bug in init.sh

If the shell test loop first finds a marginal then a good shell, the variable $gl_set_x_corrupts_stderr is still set to true and needlessly drops $VERBOSE logging. * tests/init.sh: (gl_set_x_corrupts_stderr_): Clear for successful shell. Signed-off-by: Eric Blake --- ChangeLog |6 ++

[PATCH 2/2] perror: avoid spurious test failure on HP-UX

The next-to-last command in this test has non-zero status. Even though 'exit 0' is supposed to ignore prior status, HP-UX /bin/sh favors the prior status if an exit trap is installed. * tests/test-perror.sh: Use Exit to avoid wrong exit status. Signed-off-by: Eric Blake --- ChangeLog

Re: new files imported without new modules added

On 05/24/2011 10:18 AM, Eric Blake wrote: > On 05/24/2011 10:12 AM, Sam Steingold wrote: >> Hi, >> I updated gnulib and found that it now wants to add these files to >> CLISP: >> >> src/gllib/glthread/lock.c >> src/gllib/glthread/lock.h >> src/gllib/glthread/threadlib.c >> src/gllib/strerror-impl.h

Re: new files imported without new modules added

On 05/24/2011 10:12 AM, Sam Steingold wrote: > Hi, > I updated gnulib and found that it now wants to add these files to > CLISP: > > src/gllib/glthread/lock.c > src/gllib/glthread/lock.h > src/gllib/glthread/threadlib.c > src/gllib/strerror-impl.h > src/gllib/strerror_r.c > src/glm4/strerror_r.m4

new files imported without new modules added

Hi, I updated gnulib and found that it now wants to add these files to CLISP: src/gllib/glthread/lock.c src/gllib/glthread/lock.h src/gllib/glthread/threadlib.c src/gllib/strerror-impl.h src/gllib/strerror_r.c src/glm4/strerror_r.m4 I did not import any new modules. what has happened? -- Sam St

Re: [PATCH] opendir-safer.c: don't clobber errno; don't close negative FD

On 05/24/2011 05:49 AM, Jim Meyering wrote: > Hi Eric, > > coverity reported on the potential for closing a negative file descriptor. > Fixing it, I saw/fixed the errno-clobbering problem. > > Any objection? Looks good; please apply. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt

[PATCH] opendir-safer.c: don't clobber errno; don't close negative FD

Hi Eric, coverity reported on the potential for closing a negative file descriptor. Fixing it, I saw/fixed the errno-clobbering problem. Any objection? Here's the slightly more readable form of the patch, ignoring the indentation change: diff --git a/lib/opendir-safer.c b/lib/opendir-safer.c in

Re: Move sha1 to C?

Ralf Wildenhues wrote: > It's even easier to read this way IMVHO (and just as portable): > >   sed_extract_condition2=' >     /^ *'"$escaped_dep"' *\[\(.*\)\] *$/ s//\1/p >   ' Well, "easier to read" means that you have understood this paragraph from the 'sed' specification [1] If an RE is emp