Re: [PATCH] largefile: add dependencies to this module

2011-07-25 Thread Bruno Haible
Hi Paul, > 2) Modules which do not yet exist. Here are the proposed new modules. New module Used by creat fcntl-safer fgetpos - fsetpos - fstat acl, chdir

Re: [PATCH] largefile: add dependencies to this module

2011-07-25 Thread Bruno Haible
Hi Paul, > > If you are adding a dependency to these modules, it sounds like > > every piece of application code that somehow deads with files > > via or would need a dependency to > > 'largefile'? > > That's too strong. I apologize. No offense was intended; just the heuristic

Re: fchdir / close / fclose AC_LIBOBJ cleanup

2011-07-25 Thread Bruno Haible
> This reminds me to clean up the AC_LIBOBJ invocations in this and related > *.m4 files... If it had already been cleaned up, this mistake would not > have happened. Here comes the cleanup. A series of 12 small and innocent patches. Pushed. From 1a86c594b0d0e5c65899f1bbe1cca36d501ca5d3 Mon Sep

Re: dropping close's dependency on fclose broke Octave's build system

2011-07-25 Thread Jordi Gutiérrez Hermoso
2011/7/25 Bruno Haible : > Paul Eggert wrote: >> @@ -22,5 +22,5 @@ AC_DEFUN([gl_REPLACE_CLOSE], >>    AC_REQUIRE([gl_UNISTD_H_DEFAULTS]) >>    REPLACE_CLOSE=1 >>    AC_LIBOBJ([close]) >> -  gl_REPLACE_FCLOSE >> +  m4_ifdef([gl_REPLACE_FCLOSE], [gl_REPLACE_FCLOSE]) >>  ]) > > Thanks for the fast fix

Re: dropping close's dependency on fclose broke Octave's build system

2011-07-25 Thread Bruno Haible
Paul Eggert wrote: > @@ -22,5 +22,5 @@ AC_DEFUN([gl_REPLACE_CLOSE], >AC_REQUIRE([gl_UNISTD_H_DEFAULTS]) >REPLACE_CLOSE=1 >AC_LIBOBJ([close]) > - gl_REPLACE_FCLOSE > + m4_ifdef([gl_REPLACE_FCLOSE], [gl_REPLACE_FCLOSE]) > ]) Thanks for the fast fix for my mistake, Paul! This reminds

Re: dropping close's dependency on fclose broke Octave's build system

2011-07-25 Thread Eric Blake
On 07/25/2011 08:43 AM, Paul Eggert wrote: It's on gnulib's side. I installed the following patch, which solves the immediate issue, at least for my test case. It'd be nice if someone with expertise in Cygwin/mingw/whatever would think through the implications. This is the correct patch. We

Re: pipe-filter: nice work

2011-07-25 Thread Reuben Thomas
On 25 July 2011 16:24, Paolo Bonzini wrote: > > You could pass a typed structure and let the callee use container_of or > similar macros. Nice, I wasn't aware of that trick; thanks! -- http://rrt.sc3d.org

Re: pipe-filter: nice work

2011-07-25 Thread Paolo Bonzini
On 07/23/2011 09:05 PM, Reuben Thomas wrote: I just used pipe-filter-ii to reimplement GNU Zile's shell-command (as in Emacs). It's a bit more complicated in structure than the original with all the callbacks Perhaps pipe-filter-gi can be used instead if your use case allowed you to use tempor

Re: threadlib and emacs

2011-07-25 Thread Paul Eggert
On 07/19/11 18:00, Bruno Haible wrote: > What is this AC_CACHE_CHECK good for? I've listed all the portability bugs > that were encountered during porting in > doc/posix-functions/pthread_sigmask.texi, and a wrong signature was not > among the problems found. Sorry, I expect that I misremembered a

Re: pipe-filter: nice work

2011-07-25 Thread Paolo Bonzini
On 07/23/2011 11:19 PM, Bruno Haible wrote: > The only inelegance is having > to code up a struct type to pass around the privdata argument even for > something as simple as passing data in and reading it out again. That's life, in C. A callback consists of a function pointer plus a privdata

Re: dropping close's dependency on fclose broke Octave's build system

2011-07-25 Thread Paul Eggert
On 07/24/11 18:01, Jordi Gutiérrez Hermoso wrote: > > http://octave.1599824.n4.nabble.com/Bootstrap-fails-tp3690747p3690963.html > > Not sure if we're doing something wrong in Octave with gnulib or if > it's on your side. Thanks for reporting the problem. It's on gnulib's side. I install

dropping close's dependency on fclose broke Octave's build system

2011-07-25 Thread Jordi Gutiérrez Hermoso
See this discussion: http://octave.1599824.n4.nabble.com/Bootstrap-fails-tp3690747p3690963.html Not sure if we're doing something wrong in Octave with gnulib or if it's on your side. Thanks, - Jordi G. H.

Re: [PATCH] file-has-acl: use acl_extended_file_nofollow() if available

2011-07-25 Thread Kamil Dudka
On Fri July 22 2011 15:25:13 Jim Meyering wrote: > Kamil Dudka wrote: > > On Wednesday 06 April 2011 16:49:31 Kamil Dudka wrote: > >> the attached patch allows ls(1) from coreutils to eliminate unnecessary > >> calls of getxattr() and thus prevents it from triggerring unnecessary > >> mounts while

Re: close depends on fclose?!

2011-07-25 Thread Pádraig Brady
On 24/07/11 11:39, Bruno Haible wrote: > --- modules/close.origSun Jul 24 12:37:10 2011 > +++ modules/close Sun Jul 24 12:29:07 2011 > @@ -8,7 +8,6 @@ > Depends-on: > unistd > fd-hook [test $REPLACE_CLOSE = 1] > -fclose Do we also need to remove the gl_REPLACE_FCLOSE call fr

Re: bug #17457: "grep -r foo . > somefile" goes into an infinite loop

2011-07-25 Thread Bastien ROUCARIES
On Mon, Jul 25, 2011 at 10:32 AM, Paolo Bonzini wrote: > On 07/24/2011 09:06 PM, Jim Meyering wrote: >>> >>> >  What about a few POSIX-violating fringe operating systems (Windows and >>> >  DJGPP come to mind)?:)   For Windows we can write our own stat >>> >  function in cygwin, but for DJGPP I th

Re: bug #17457: "grep -r foo . > somefile" goes into an infinite loop

2011-07-25 Thread Paolo Bonzini
On 07/24/2011 09:06 PM, Jim Meyering wrote: > What about a few POSIX-violating fringe operating systems (Windows and > DJGPP come to mind)?:) For Windows we can write our own stat > function in cygwin, but for DJGPP I think we're in a bad situation... AFAIK, DJGPP is not relevant these days