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 interpret the first
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
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. Notably, I changed
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
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 other
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
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
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.
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, char * const *
