Re: [PATCH] New fallocate module

2009-05-22 Thread Pádraig Brady
Paul Eggert wrote: > Pádraig Brady writes: > >> Well libc, kernel or filesystem could return ENOSYS >> so code using fallocate() has to handle it anyway. > > If memory serves, ordinarily gnulib tries to catch such situations, > and to substitute a working function when the kernel just has a stub

Re: [PATCH] New fallocate module

2009-05-22 Thread Paul Eggert
Pádraig Brady writes: > Well libc, kernel or filesystem could return ENOSYS > so code using fallocate() has to handle it anyway. If memory serves, ordinarily gnulib tries to catch such situations, and to substitute a working function when the kernel just has a stub that returns ENOSYS. However,

Re: [PATCH] New fallocate module

2009-05-22 Thread Pádraig Brady
Bruno Haible wrote: > Hello Pádraig, > > The documentation files you sent document the status before any 'fallocate' > module is added to gnulib. So I committed them for you: > > 2009-05-21 Pádraig Brady > > * doc/glibc-functions/fallocate.texi: New file. > * doc/gnulib.texi: Incl

Re: open_safer on amd64

2009-05-22 Thread Jim Meyering
Bruno Haible wrote: > Eric Blake wrote: >> We could also check at configure time for AC_CHECK_SIZEOF([mode_t]), then >> use the preprocessor to skip the unneeded branch altogether using the >> appropriate macro from config.h. > > Yes. Paul Eggert tried to avoid configure-time checks that could also

Re: [PATCH] New fallocate module

2009-05-22 Thread Bruno Haible
Hello Pádraig, The documentation files you sent document the status before any 'fallocate' module is added to gnulib. So I committed them for you: 2009-05-21 Pádraig Brady * doc/glibc-functions/fallocate.texi: New file. * doc/gnulib.texi: Include it. The fallocate.texi will n