fileblocks: missing declaration of st_blocks?

I notice that the fileblocks module defines st_blocks, but there's no declaration for it. Is that deliberate? James.

Re: test-rmdir on HP-UX 10.20

On 06/08/2011 03:03 PM, Bruno Haible wrote: > Similarly, on HP-UX 10.20 I observe this failure: > > test-rmdir.h:69: assertion failed > FAIL: test-rmdir > > This fixes it. OK to apply? Yep, go ahead. >ASSERT (func (BASE "dir/.//") == -1); > - ASSERT (errno == EINVAL || errno == EBUSY |

Re: [PATCH] New module 'stat-size'.

Hi James, > +AC_DEFUN([gl_STAT_SIZE], > +[ > +  # AC_STRUCT_ST_BLOCKS may add fileblocks to AC_LIBOBJ. > +  AC_STRUCT_ST_BLOCKS > +  AC_CHECK_HEADERS_ONCE([sys/param.h]) > +]) No more AC_LIBOBJ invocations from .m4 files, please! It causes bugs, see [1] for details. Actually AC_STRUCT_ST_BLOCKS

[PATCH] New module 'stat-size'.

* modules/stat-size: New module. Provides macros for accessing file size informaiton in instances of struct stat. Depends on the fileblocks module because it calls st_blocks. * lib/stat-size.h: New file, adapted from coreutils' system.h. * doc/gnulib.texi: Include stat-size.texi. * doc/stat-size.

Re: [PATCH 1/2] stat-macros: Enhance to provide block-related information.

On Wed, Jun 8, 2011 at 1:43 AM, Paul Eggert wrote: >>  Depends-on: >> +sys_stat >> +stdint > > We can break the dependency on the stdint module > by using (size_t) -1 instead of SIZE_MAX. Thanks for the tip. > Why does stat-macros need to depend on sys_stat? Because ST_NBLOCKS uses S_ISREG, for

test-rmdir on HP-UX 10.20

Hi Eric, Ralf Wildenhues wrote on 2010-08-25 in : > Fix test-unlinkat, test-rmdir failure on AIX 5.3. > > * tests/test-rmdir.h: Also accept EEXIST for > rmdir ("dir/.//"), unlinkat. > > diff --git a/tests/test-rm

Re: test-lock compilation failure on mingw

On 06/08/11 07:43, Eric Blake wrote: > test-lock.c: In function lock_mutator_thread: > test-lock.c:146:7: error: cannot convert to a pointer type > > and many more like it; apparently, the new cygwin cross-compiler for mingw: > > i686-pc-mingw32-gcc (GCC) 4.5.2 > > doesn't like converting gl_thr

test-lock compilation failure on mingw

test-lock.c: In function lock_mutator_thread: test-lock.c:146:7: error: cannot convert to a pointer type and many more like it; apparently, the new cygwin cross-compiler for mingw: i686-pc-mingw32-gcc (GCC) 4.5.2 doesn't like converting gl_thread_self() into void* as a printf() argument. -- Er

Re: errno --> errno name ?

Hi Thien-Thi, > Accretion: the coral reef's algorithm. ;-) >Would you be willing to create a gnulib module from this, for Sam? > > For Sam and anyone else interested, sure. What needs to be done? Create a .h file with the specification of the function. Create a .c file with the implementa

[PATCH] perror: fix test on mingw

test-perror2 was tripping up on a known mingw dup2 pitfall. * modules/perror-tests (Depends-on): Add dup2. Signed-off-by: Eric Blake --- With this, mingw passes perror, strerror, and strerror_r unit tests, but still fails test-lock (see separate mail). ChangeLog|5 + modul

Re: [PATCH 2/2] strerror: work around FreeBSD bug

On 06/07/2011 09:50 PM, Eric Blake wrote: > Oh hideous. > > strerror(0) => Unknown error: 0 > strerror_r(0,buf,len) => Undefined error: 0 > strerror(-1) => Unknown error: -1 > strerror_r(-1,buf,len) => Unknown error: -1 > > I don't think POSIX requires the same strings for the two > implementatio

[PATCH] strerror_r-posix: fix on MacOS

MacOS X 10.5 strerror(0) is "Unknown error: 0", which is not distinguished from "Unknown error: -1" for out-of-range. Worse, strerror_r(0,,) is "Undefined error: 0", although strerror_r for all other out-of-range values matches strerror. * m4/strerror.m4 (gl_FUNC_STRERROR): Flush out MacOS bug. *

Re: MacOS strerror_r

On 06/08/2011 05:38 AM, Eric Blake wrote: > I fixed that, and found the next bug: > > $ ./foo 1 23 > Operation not permitte(34) > $ ./foo 1 24 > Operation not permitted(0) > > Ouch. MacOS is _silently_ writing a NUL byte beyond the array bounds, > if the input buffer size is exactly equal to str

MacOS strerror_r [was: [PATCH 2/2] strerror: work around FreeBSD bug]

On 06/07/2011 09:50 PM, Eric Blake wrote: >> strerror(0) misbehavior. Hmm, while FreeBSD was setting EINVAL to make >> the failure explicit, MacOS is claiming success while still outputting >> "Unknown error: 0". I'll fix that with a strstr() test in the .m4 files. > > Oh hideous. > > strerror(

Re: [PATCH 2/2] strerror_r-posix: work around cygwin 1.7.9

On 06/08/2011 04:36 AM, Bruno Haible wrote: > Hi Eric, > >> the 'strerror' module in isolation will not replace strerror, but >> if strerror_r is in use for any other reason, then the two use >> separate buffers. > > Very nice. Good improvement. > > I'm applying a couple of follow-up tweaks: Th

Re: errno --> errno name ?

() Bruno Haible () Wed, 8 Jun 2011 11:26:42 +0200 Its list of errno values is pretty extensive, good. Accretion: the coral reef's algorithm. Would you be willing to create a gnulib module from this, for Sam? For Sam and anyone else interested, sure. What needs to be done?

Re: [PATCH 2/2] strerror_r-posix: work around cygwin 1.7.9

Hi Eric, > the 'strerror' module in isolation will not replace strerror, but > if strerror_r is in use for any other reason, then the two use > separate buffers. Very nice. Good improvement. I'm applying a couple of follow-up tweaks: - In gl_FUNC_STRERROR, we don't need to emit code in configu

Re: [PATCH 1/2] stat-macros: Enhance to provide block-related information.

Paul Eggert wrote: > It'd be good to add something like this, thanks. Thanks, James. I like your idea, too. Those definitions are duplicated in far too many packages. > A few comments: > > The time-related stat macros are already broken out into > stat-time.h. Perhaps these size-related macros

Re: errno --> errno name ?

Sam Steingold wrote: > note that the windows version would have to operate on the values of > GetLastError() instead of errno. Native Windows programs have to deal with both GetLastError() and errno. It would be wrong for an API to handle errno values on Unix but to not handle errno values on ming

Re: errno --> errno name ?

On 06/07/2011 12:38 AM, Sam Steingold wrote: note that the windows version would have to operate on the values of GetLastError() instead of errno. At least this part does not belong in gnulib, I think, because gnulib tries to map Windows errors to errno values whenever necessary. You would s

Re: errno --> errno name ?

Thien-Thi Nguyen wrote: > The referenced script mksyms is attached. Its list of errno values is pretty extensive, good. Would you be willing to create a gnulib module from this, for Sam? Bruno -- In memoriam Larisa Yudina