Re: socklen_t on HP/UX

Dustin J. Mitchell wrote: > As you probably know, on HP/UX, accept, getpeername, et al. take (.., > int *addrlen), not (.., socklen_t *addrlen) unless _XOPEN_SOURCE and > _XOPEN_SOURCE_EXTENDED are defined. However, if these macros are not > defined, socklen_t is still defined. There are a few mo

socklen_t on HP/UX

As you probably know, on HP/UX, accept, getpeername, et al. take (.., int *addrlen), not (.., socklen_t *addrlen) unless _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED are defined. However, if these macros are not defined, socklen_t is still defined. This means that the test in socklen.m4 doesn't have

Re: parsing issue ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [adding bug-gnulib] According to Longuet JeanCharles on 5/19/2008 11:44 AM: | | | PS: Not sure this is related, but I did this test with the last version (1.4.11) of m4, and a "make test" failed with : | FAIL: test-fseeko.sh | test-ftello.c:92: asser

Re: Error During cpio Make

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Brian Eliassen on 5/19/2008 2:38 PM: | AlphaServer ES45 with Tru64 5.1B running the built-in “cc” C complier. | | source='imaxtostr.c' object='imaxtostr.o' libtool=no \ | DEPDIR=.deps depmode=tru64 /usr/bin/posix/sh ../build-aux/d

Re: memcmp and cross-compilation

Simon Josefsson wrote: > The patch below works in the sense that, for cross-compilations only, it > will assume that memcmp works when it is declared. This works better > for MinGW. This is good. It's the usual approach we take for cross-compiles in gnulib: Put in the known cases into the autocon

Re: memcmp-tests module

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> The first part of this was adding a self-test for memcmp. >> I'm sure it can be improved to test more corner cases, but this is much >> better than nothing. Pushed. > > It's good habit to include the tests from the autoconf macr

Re: memcmp-tests module

Simon Josefsson wrote: > The first part of this was adding a self-test for memcmp. > I'm sure it can be improved to test more corner cases, but this is much > better than nothing. Pushed. It's good habit to include the tests from the autoconf macro also in the test suite (to verify that the autoc

Re: rpl_memcmp on mingw with g++?

Simon Josefsson wrote: > MinGW apparently needs gnulib's memcmp module, which adds this to > config.h: > > #define memcmp rpl_memcmp It doesn't need it. I just checked the MSVCRT source code: its memcmp implementation is correct. Bruno

Re: memcmp and cross-compilation

Simon Josefsson <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> Simon Josefsson <[EMAIL PROTECTED]> writes: >> >>> MinGW apparently needs gnulib's memcmp module >> >> That was rather surprising to me, so I started investigating why that is >> the case. > > The reason

memcmp and cross-compilation (was: Re: memcmp-tests module)

Simon Josefsson <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> MinGW apparently needs gnulib's memcmp module > > That was rather surprising to me, so I started investigating why that is > the case. The reason was that Autoconf's AC_FUNC_MEMCMP uses AC_RUN_IFELSE wi

memcmp-tests module (was: Re: rpl_memcmp on mingw with g++?)

Simon Josefsson <[EMAIL PROTECTED]> writes: > MinGW apparently needs gnulib's memcmp module That was rather surprising to me, so I started investigating why that is the case. The first part of this was adding a self-test for memcmp. I'm sure it can be improved to test more corner cases, but this

rpl_memcmp on mingw with g++?

All, MinGW apparently needs gnulib's memcmp module, which adds this to config.h: #define memcmp rpl_memcmp This appears to cause problems for the standard C++ headers, see complete error below. What is a good solution here? Is there another way to replace memcmp that is safer? Should the C++