Re: add license to link-warning.h

2009-12-09 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 12/9/2009 10:56 AM: > Plus a useless use of cat, for a total of 3 processes? Come on, we can do > better than that. A single sed process is sufficient, by rephrasing the > problem (rather than what do we want to exclude,

Re: cloexec license

2009-12-09 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 12/9/2009 1:57 AM: > Eric Blake wrote: >> Any objections to relicensing cloexec as LGPL? > > Fine with me. If anyone asks for LGPLv2+ for this code, that would also be > fine with me. I just went for LGPL for now; committ

Re: untabify - last call for objections

2009-12-09 Thread Karl Berry
*** README.orig 2009-12-09 20:16:50.0 +0100 --- README 2009-12-09 19:36:18.0 +0100 How about adding everything in README to gnulib.texi, and generating it? The README grows and grows, in both length and importance ...

Re: {un,}setenv fixes

2009-12-09 Thread Bruno Haible
Eric Blake wrote on 2009-11-17: > unsetenv(name) only cleared the first instance, even if (ab)use of > putenv, or assignment to environ, included duplicates of name. > > * m4/setenv.m4 (gl_FUNC_UNSETENV): Check for bug. > * lib/unsetenv.c (rpl_unsetenv): Work around it. I'm adding doc about this

Re: untabify - last call for objections

2009-12-09 Thread Jim Meyering
Jim Meyering wrote: > Bruno Haible wrote: >> What should I write in the NEWS file, about recommendations for people who >> have >> patches on top of gnulib? > > We also need a way to keep things in order going forward. > I.e., a syntax-check style rule that enforces this style. > > To that end, p

Re: untabify - last call for objections

2009-12-09 Thread Jim Meyering
Bruno Haible wrote: > What should I write in the NEWS file, about recommendations for people who > have > patches on top of gnulib? We also need a way to keep things in order going forward. I.e., a syntax-check style rule that enforces this style. To that end, please prepare a file like the one

Re: untabify - last call for objections

2009-12-09 Thread Bruno Haible
Hi Jim, all, Here's the proposal for untabifying: - all *.m4 files, - all *.sh files, - all *.[chy] files except lib/reg* The entire patch is at http://www.haible.de/bruno/gnu/gnulib-expand.diff.gz (768 KB). The interesting parts are below: 1) Changes to NEWS and README (thanks Paolo for t

Re: add license to link-warning.h

2009-12-09 Thread Eric Blake
Bruno Haible clisp.org> writes: > > The empty line after the copyright header was intended to be removed as well. > This appears to require two sed pipes in a row. Plus a useless use of cat, for a total of 3 processes? Come on, we can do better than that. A single sed process is sufficient,

Re: [PATCH] progname: don't segfault when argv is NULL

2009-12-09 Thread Bruno Haible
Jim Meyering wrote: > The POSIX spec for execve says this about envp: > > The argument envp is an array of character pointers to null-terminated > strings. These strings shall constitute the environment for the new > process image. The envp array is terminated by a null pointer. > > w

Re: [PATCH] progname: don't segfault when argv is NULL

2009-12-09 Thread Jim Meyering
Bruno Haible wrote: > About the exec* functions: >> Ad 1): >> > I suggest you declare those functions with the "nonnull" attribute. >> >> Good idea. I reported this to glibc: >> > > It has been committed: gcc+glibc will now warn if a user use

Re: [PATCH] progname: don't segfault when argv is NULL

2009-12-09 Thread Jim Meyering
Bruno Haible wrote: >> perhaps incomplete, since you can make the same argument about the "envp" >> pointer. > > How so? >From the perspective that since POSIX disallows passing a NULL pointer, it would make sense to label each corresponding parameter with the nonnull attribute. Not a big deal, t

Re: [PATCH] progname: don't segfault when argv is NULL

2009-12-09 Thread Bruno Haible
About the exec* functions: > Ad 1): > > I suggest you declare those functions with the "nonnull" attribute. > > Good idea. I reported this to glibc: > It has been committed: gcc+glibc will now warn if a user uses a NULL argv array in an exec

Re: add license to link-warning.h

2009-12-09 Thread Simon Josefsson
Bruno Haible writes: > I'm applying this: Thanks! Jim's change looks fine too. /Simon

Re: add license to link-warning.h

2009-12-09 Thread Bruno Haible
Hi Jim, > the bootstrap script, > which prepends lines like these to build-aux/link-warning.h: > > /* -*- buffer-read-only: t -*- vi: set ro: */ > /* DO NOT EDIT! GENERATED AUTOMATICALLY! */ > > In that case, the hard-coded "17" is incorrect Oops, sure. I wasn't aware of these extra lin

Re: add license to link-warning.h

2009-12-09 Thread Jim Meyering
Bruno Haible wrote: >> Bruno, what do you think? For rationale, I got a comment in >> https://savannah.gnu.org/task/?9954 that link-warning.h lacked licensing >> information. > > With the coding guideline that every file should have a copyright statement, > and the license audits that they do in D

Re: mgetgroups improvements

2009-12-09 Thread Bruno Haible
Eric Blake wrote: > Are there any implementations > of malloc/realloc where malloc(0) does not return dereferencable memory at > least sizeof(gid_t) in length? Sure. The malloc in ElectricFence. With it, malloc(0) = malloc(1) returns a single byte at the end of a memory page, with the next memory

Re: mgetgroups improvements

2009-12-09 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 12/9/2009 2:31 AM: >> + { >> +gid_t first = *g; > > This code will do an invalid memory access if ng == 0 (which can happen if > gid == (gid_t) -1 and getgroups or getugroups does not find a gid). Good catch. And I

Re: fchdir fixes

2009-12-09 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 12/9/2009 4:11 AM: > Eric Blake wrote: >> ... a link failure on rpl_fstat. >> ... >> * lib/fchdir.c (rpl_fstat): Always provide if fchdir replacement >> is in use. > > If !REPLACE_OPEN_DIRECTORY the rpl_fstat does nothing

Re: add license to link-warning.h

2009-12-09 Thread Bruno Haible
Hi Simon, > Bruno, what do you think? For rationale, I got a comment in > https://savannah.gnu.org/task/?9954 that link-warning.h lacked licensing > information. With the coding guideline that every file should have a copyright statement, and the license audits that they do in Debian, I nearly s

Re: fchdir fixes

2009-12-09 Thread Bruno Haible
Eric Blake wrote: > ... a link failure on rpl_fstat. > ... > * lib/fchdir.c (rpl_fstat): Always provide if fchdir replacement > is in use. If !REPLACE_OPEN_DIRECTORY the rpl_fstat does nothing else than to call fstat. We don't need rpl_fstat in this case. I'm applying this optimization. I've verif

Re: iruserok

2009-12-09 Thread Simon Josefsson
FYI, the glibc bug for this is: http://sources.redhat.com/bugzilla/show_bug.cgi?id=11070 /Simon

iruserok

2009-12-09 Thread Simon Josefsson
InetUtils rshd failed to build on Mac OS X for another reason: rshd.c:178: error: conflicting types for 'iruserok' /usr/include/unistd.h:514: error: previous declaration of 'iruserok' was here The rshd.c line 178 is: extern int iruserok (uint32_t raddr, int superuser, const

Re: fix mkostemp, add pipe2-safer

2009-12-09 Thread Bruno Haible
Eric Blake wrote: > On cygwin, native fcntl(F_DUPFD), dup, and dup2; and our > version of dup_cloexec, already copy the text/binary mode of the source. > So why not make mingw do the same, rather than blindly slamming to O_BINARY. > ... > Here's what I've tested on mingw and cygwin; now pushed. Lo

Re: fix mkostemp, add pipe2-safer

2009-12-09 Thread Bruno Haible
Hi Eric, > > - In set_cloexec_flag: You added a call to > > dup2 (desc, desc) > > But on a POSIX compliant system this is a no-op, since > > Not quite. It is the fastest one-syscall sequence for determining whether > an fd is open Oh, I see. That wasn't clear to me. > Okay, then, a comme

Re: mgetgroups improvements

2009-12-09 Thread Bruno Haible
Hi Eric, > + /* Reduce the number of duplicates. On some systems, getgroups > + returns the effective gid twice: once as the first element, and > + once in its position within the supplementary groups. On other > + systems, getgroups does not return the effective gid at all, > +

Re: cloexec license

2009-12-09 Thread Bruno Haible
Eric Blake wrote: > Any objections to relicensing cloexec as LGPL? Fine with me. If anyone asks for LGPLv2+ for this code, that would also be fine with me. Bruno