Re: style question - const char *

Jim Meyering wrote: > Paul Eggert <[EMAIL PROTECTED]> wrote: > > Eric Blake <[EMAIL PROTECTED]> writes: > >> Is there a preference for 'const char *' over 'char const *'? > > > > I prefer putting type qualifiers like "const" after the types they > > modify, as that's more consistent. For example,

Re: test failures building 5.93 and hpux compiler patch

"Peter O'Gorman" <[EMAIL PROTECTED]> writes: > The HP-UX 10.20 compiler is documented to fail on switch statements with > 64 bit values, so yes, that test causes it to crash. However, the > problem only occurs with re_search which returns a regoff_t which is an > off_t which is, correctly, 64 bits

Separate csharpcomp.sh, and a license problem

After including the csharpcomp module in libidn, I realized I don't need any of the C code in that module. I just need csharpcomp.sh.in, csharp.m4 and csharpcomp.m4. How about installing the following csharpcomp-script module for those files, and patching the csharpcomp module to depend on the fo

Re: socklen_t

Paul Eggert <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> Thanks for doing this! I will test this shortly. > > You're welcome. I have installed the file in GNUTLS and GNU SASL. I haven't done any testing yet, but if any problem appear I'll report them. I think

Unconditionally call AC_PROG_RANLIB?

Hi! I'm trying to use the csharpcomp module to build the libidn C# port. I'm setting this up in a separate directory. Running autoconf on the gnulib generated stuff results in: lib/Makefile.am:15: library used but `RANLIB' is undefined lib/Makefile.am:15: lib/Makefile.am:15: The usual way to de

Re: socklen_t

Paul Eggert <[EMAIL PROTECTED]> writes: > You're welcome. One thing I forgot to mention: the old m4/socklen.m4 > code is obviously incorrect because of the stray parenthesis in this > line: > > #endif) > > That parenthesis is copied into the C header used for testing. > > GCC doesn't mind, but ot

Re: socklen_t

Simon Josefsson <[EMAIL PROTECTED]> writes: > Thanks for doing this! I will test this shortly. You're welcome. One thing I forgot to mention: the old m4/socklen.m4 code is obviously incorrect because of the stray parenthesis in this line: #endif) That parenthesis is copied into the C header u

Re: FYI: new openat-like function: mkdirat

Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > You're talking about exec. If you're going to use execve anyway, > there's no way you need your old initial working directory back, is > there? Right. As James pointed out, the forked child can simply call fchdir just before execvp, just as find alr

Re: socklen_t

Paul Eggert <[EMAIL PROTECTED]> writes: > Albert Chin <[EMAIL PROTECTED]> writes: > >> Ok, paperwork is complete. I don't have time to submit a patch. Can >> someone else do so? > > OK, everybody, how about this patch? I haven't tested it; all I've > done is combined everybody's comments. Notabl

Re: FYI: new openat-like function: mkdirat

On Wed, Nov 30, 2005 at 09:53:53PM +0100, Jim Meyering wrote: > Roland McGrath <[EMAIL PROTECTED]> wrote: > > I think that the Solaris *at functions were really primarily intended for > > use with O_XATTR to get at "file attribute" magic pseudo-directories rather > > than to optimize use of normal

Re: FYI: new openat-like function: mkdirat

On Wed, Nov 30, 2005 at 11:34:40PM +0100, Jim Meyering wrote: > Roland McGrath <[EMAIL PROTECTED]> wrote: > >> So I guess the exec*at business would ultimately be more complicated, > >> with two file descriptor parameters: one identifying the working > >> directory, and another by which to interpre