Good suggestion; thanks. I installed this into gnulib: 2007-10-17 Paul Eggert <address@hidden> Modify glob.c to use fstatat and dirfd, to simplify it. Suggested by Eric Blake. * lib/glob.c (__fxstata
That bug isn't in the libc version. At this point it's probably better to sync the gnulib version from libc, so I installed this: 2007-10-16 Paul Eggert <address@hidden> Merge glibc changes into lib/
Sam Steingold wrote: gnulib-tool --import --source-base=src/gllib --m4-base=src/glm4 \ --aux-dir=src/build-aux --no-changelog \ stdint stdbool ... This will create a Makefile.am in src/gllib; theref
It's a good idea to do it, say, two weeks before a release, and then watch the bug-gnulib mailing to see whether the files you have imported may be broken. (It happens that we have broken files in th
I could live with ".in.h". However, I fear that if we depend on an "ok" from the Emacs maintainers, then neither "..h" nor ".in.h" will fly. Currently, no file name in emacs contains more than one ".
I can accept "..h", but I prefer ".in.h", so as to remind the substitution of autoconf macros. You need to ask the Emacs maintainers whether they can accept file names with two dots in them (DOS, VMS
kate and vi apply the same syntax coloring to getopt..h as to getopt.h as well. So, yes, on this side, "..h" is as good as ".h". The brevity strikes back sometimes: when an outsider sees fcntl_.h and
Hi Jim, Another reason is that - especially in gnulib - file names are often named after a C function. When a source file provides a function named 'pagealign_alloc', it would be confusing to call th
Plenty of packages have used it for 10 years or longer: GCC installs or installed files in $prefix/include/g++, and a library called libstdc++. binutils has a program called 'c++filt'. gettext is usi
I may have found a bug in the gnulib regex code, but the first step before fixing it is to import recent changes from libc, so I installed this: 2006-08-10 Paul Eggert <address@hidden> Import the fol
Can the Windows guys supply a dirent.h substitute module? That would let you do the futher simplification. Yes. For now, let's remove the vmsdir.h stuff since I don't think anybody uses it now. If it
Bruno & bug-gnulib, sorry for the double-copy, but I realized belatedly that it may be useful to CC bug-cvs on this one: - -- Derek R. Price CVS Solutions Architect Get CVS support at Ximbiot <http:/
Thanks, Bruno. I've attached a patch that replaces all the references to AC_HEADER_DIRENT with calls to AC_CHECK_HEADERS_ONCE([dirent.h ndir.h]) and makes the accompanying changes in lib/*. This patc
But POSIX specifies all three points, so when implementing a POSIX version of m4, it would be nice to rely on POSIX semantics of system(). I thought one of gnulib's goals was to provide useful POSIX
Eric Blake asked: The specification of system() in ISO C 99 does not specify 1) which is the command processor, and in particular which are the built-in commands and how to quote arguments when const
With this, getopt actually do seem to compile and work in Visual Studio. Tested with the CLI in libtasn1, part of GnuTLS, with long options. I'll install this shortly unless someone protests. 2006-02
With this, getopt actually do seem to compile and work in Visual Studio. Tested with the CLI in libtasn1, part of GnuTLS, with long options. I'll install this shortly unless someone protests. 2006-02
Thanks for reporting these. The quotearg problem is actually a bug in GCC (it generates an improper warning). Jim Meyering has already installed a workaround that generates slightly-worse code but av