Re: glob_.h & glibc

Paul Eggert wrote: >Hmm, actually they provisionally accepted the bug-1060 changes except >for the part about using prototypes when defining external functions. > > Oh, that's what that meant. I was hoping someone else would say something if it was important. Thanks. :) >where glob-libc.h i

Re: glob_.h & glibc

It's late, I'm tired. Patches actually attached now. 2005-09-08 Derek Price <[EMAIL PROTECTED]> * m4/glob.m4 (gl_GLOB_SUBSTITUTE): AC_LIBSOURCE C files. * lib/glob_.h: Move most code forked from glibc here, then include... * lib/glob-glibc.h: ...this new file, which is the original

newlib bug in argz_insert

I discovered and patched a newlib bug in argz_insert today (http://sources.redhat.com/ml/newlib/2005/msg00516.html): when the before argument was NULL, it was dying with EINVAL rather than correctly appending to the end. Is it worth updating m4/argz.m4 to detect this bug on systems using old newli

Re: utimens depends on utime

Sergey Poznyakoff <[EMAIL PROTECTED]> writes: > Hmm, now I see a better solution: to list m4/utimbuf.m4 in Files > section of modules/utimens. Right you are. I installed that. 2005-09-08 Paul Eggert <[EMAIL PROTECTED]> * modules/utimens (Files): Add m4/utimbuf.m4, since m4/ut

Re: utimens depends on utime

Paul Eggert <[EMAIL PROTECTED]> wrote: > Sergey Poznyakoff <[EMAIL PROTECTED]> writes: > > > The module utimens depends on utime, > > Could you please explain why? Because m4/utimens.m4 AC_REQUIREs gl_CHECK_TYPE_STRUCT_UTIMBUF, which is defined in m4/utimbuf.m4, which is listed in Files section

Re: utimens depends on utime

Sergey Poznyakoff <[EMAIL PROTECTED]> writes: > The module utimens depends on utime, Could you please explain why? As I understand it, the utime module is needed only for ancient 4.3BSD-based systems where the utime function mishandles NULL arguments. Such systems are no longer in use (and have

Re: glob_.h & glibc

Derek Price <[EMAIL PROTECTED]> writes: > Re: , glibc > objected to the extent of our changes to an installed header (glob.h) to > bring the file into sync with GNULIB. (They did accept the glob.c > changes, though they have yet to apply them.)

Re: AC 2.59 incompatibility in getaddrinfo.h

Derek Price <[EMAIL PROTECTED]> writes: > Is there any reason I can't just assume gl_GETADDRINFO ran and config.h > was included before getaddrinfo.h? The following test is always coming > up false on platforms without getaddrinfo (as of AC 2.59, at least, > AC_CHECK_FUNCS via AC_REPLACE_FUNCS le

Re: socklen_t

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> Can I install this? Albert Chin proposed a better M4 test, but the >> legal procedure will take time, and I'm already using my version in a >> few projects. When the legal problems has been fixed, we can change >> it to use the

Re: AC 2.59 incompatibility in getaddrinfo.h

Paul Eggert wrote: >>shortening the above test to: "# if !HAVE_GETADDRINFO", and I'd >>rather just simplify the header >> >> > >Yes, that sounds right. > > Okay, thanks, Paul. I've committed this to CVS CVS for more testing before I finish importing it into GNULIB. Cheers, Derek -- Der

Re: AC 2.59 incompatibility in getaddrinfo.h

Derek Price <[EMAIL PROTECTED]> writes: > shortening the above test to: "# if !HAVE_GETADDRINFO", and I'd > rather just simplify the header Yes, that sounds right. I think the "defined HAVE_GETADDRINFO" cruft dates way back to when we weren't so sure that the Autoconf macro was part of a distrib

Re: [bug-gnulib] Re: socklen_t

Simon Josefsson wrote: > Can I install this? Albert Chin proposed a better M4 test, but the > legal procedure will take time, and I'm already using my version in a > few projects. When the legal problems has been fixed, we can change > it to use the new macro and test that. What do you think? A

glob_.h & glibc

Re: , glibc objected to the extent of our changes to an installed header (glob.h) to bring the file into sync with GNULIB. (They did accept the glob.c changes, though they have yet to apply them.) It is true, as Roland says, that we could put mo

AC 2.59 incompatibility in getaddrinfo.h (was Re: canon-host errors)

Is there any reason I can't just assume gl_GETADDRINFO ran and config.h was included before getaddrinfo.h? The following test is always coming up false on platforms without getaddrinfo (as of AC 2.59, at least, AC_CHECK_FUNCS via AC_REPLACE_FUNCS leaves HAVE_GETADDRINFO undefined when it is not fo

Re: socklen_t

Can I install this? Albert Chin proposed a better M4 test, but the legal procedure will take time, and I'm already using my version in a few projects. When the legal problems has been fixed, we can change it to use the new macro and test that. What do you think? Simon Josefsson <[EMAIL PROTECTE

utimens depends on utime

The module utimens depends on utime, however this dependency is not listed in modules/utimens. This can be fixed by the following patch: Index: modules/utimens === RCS file: /cvsroot/gnulib/gnulib/modules/utimens,v retrieving revision