Re: more m4 quoting

Eric Blake wrote: > > What's the rationale of quoting purely numeric m4 arguments, like in > >AC_DEFINE([FOO], [1], ...) ? > > It looks a bit like clutter to me, since quoting does not matter here. But > > if you and Eric and Simon are willing to do this purely for consistency, > > I'm going w

Re: #ifndef _GL_WCHAR_H in lib/wchar.in.h

Hi Albert, > Why does lib/wchar.in.h have: > #ifndef _GL_WCHAR_H > ... > #ifndef _GL_WCHAR_H > #define _GL_WCHAR_H > rather than just: > #ifndef _GL_WCHAR_H > #define _GL_WCHAR_H This is the necessary idiom when using #include_next. > This causes a problem on HP-UX 11.00 because is

Re: sys/stat.h and nlink

Simon Josefsson wrote: > I see two solutions. I pushed 2). Thanks. This was the right choice, because POSIX [1] specifies "The header shall define the ... nlink_t, ... types as described in ." Bruno [1] http://www.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html

Re: set_program_name behavior

Hello Sergey, > The behavior of set_program_name differs depending on whether argv[0] > refers to a libtool script (*/.libs/lt-*) or to a usual binary. In the first > case, the function strips off all directory components and the `lt-' > prefix, and assigns the result to program_name. In the secon

Re: C++ patch for m4/mktime.m4

On Wed, Jan 14, 2009 at 07:42:50PM +0100, Jim Meyering wrote: > Albert Chin wrote: > > The Sun C++ compiler fails to compile the test case in m4/mktime.m4 > > correctly because of the K&R style function prototypes. Patch attached. > > Hi Albert, > > That patch looks fine. > Would you please writ

Re: sys/stat.h and nlink

Simon Josefsson wrote: > The test-sys_stat self-test fails on debian etch x86, see: > > http://autobuild.josefsson.org/gnulib/log-200901140954236318000.txt > > The problem is that sys/stat.h does not define nlink_t (at least not > unconditionally), however sys/types.h does: > > gnu...@mejsel:~$ ca

Re: C++ patch for m4/mktime.m4

Albert Chin wrote: > The Sun C++ compiler fails to compile the test case in m4/mktime.m4 > correctly because of the K&R style function prototypes. Patch attached. Hi Albert, That patch looks fine. Would you please write a ChangeLog entry and then send git format-patch output to the list? Then,

C++ patch for m4/mktime.m4

The Sun C++ compiler fails to compile the test case in m4/mktime.m4 correctly because of the K&R style function prototypes. Patch attached. -- albert chin (ch...@thewrittenword.com) diff --git a/m4/mktime.m4 b/m4/mktime.m4 index 5faf393..75e55c5 100644 --- a/m4/mktime.m4 +++ b/m4/mktime.m4 @@ -68

#ifndef _GL_WCHAR_H in lib/wchar.in.h

Why does lib/wchar.in.h have: #ifndef _GL_WCHAR_H ... #ifndef _GL_WCHAR_H #define _GL_WCHAR_H rather than just: #ifndef _GL_WCHAR_H #define _GL_WCHAR_H This causes a problem on HP-UX 11.00 because is included more than once. $ ./gnulib-tool --create-testdir --dir=t arpa_inet crypto/

sys/stat.h and nlink

The test-sys_stat self-test fails on debian etch x86, see: http://autobuild.josefsson.org/gnulib/log-200901140954236318000.txt The problem is that sys/stat.h does not define nlink_t (at least not unconditionally), however sys/types.h does: gnu...@mejsel:~$ cat>foo.c #include int main (void) { n

set_program_name behavior

Hello, The behavior of set_program_name differs depending on whether argv[0] refers to a libtool script (*/.libs/lt-*) or to a usual binary. In the first case, the function strips off all directory components and the `lt-' prefix, and assigns the result to program_name. In the second case, however

Re: unistdio/u16-printf-parse on debian etch

Bruno Haible writes: > Thanks. A couple of similar modules have the same mistake. I'm applying this > followup: Great. Btw, aren't the file names stdint_h.m4 and inttypes_h.m4 confusing? I don't have a better suggestion though. /Simon