Re: 0 vs. NULL

Micah Cowan wrote: > it is not safe to assume that using NULL, addresses those > argument-passing problems To be > portable, it must be cast when passed as a vararg param. Indeed! Good point. Compilers such as Sun C++ really define NULL to 0 (in both C and C++ mode!), and misinterpret NULL in

Re: 0 vs. NULL

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bruno Haible wrote: > Ben Pfaff wrote: >> ISO C says that NULL can be defined as 0, without a cast to void >> *, and it is always defined that way in C++. > > The latter statement is not true. ISO C++ 18.1.(3) says: > > "The macro NULL is an impl

Re: newlib platform

On Oct 13, 2007, at 11:00 PM, Bruno Haible wrote: Benoit SIGOURE wrote: FYI, I needed a replacement of `trunc' and `round' for mipsel- linux-g++-3.3.2 with newlib-1.10.0. Do you feel that newlib is an important platform? I don't know really. I had to use it because that's what comes in t

Re: Fwd: Re: error.c: "Unknown system error" should report errno value (fwd)

On Sat, 13 Oct 2007, Bruno Haible wrote: Martin Koeppe wrote: The relevant output is done by asprintf(). And by printf() in line 269. That's it. coreutils needs to use also printf-posix, not only vasprintf-posix. Then 'seq' should work. Or modify seq to not use printf() so that not every c

Re: newlib platform

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 10/13/2007 3:00 PM: > Benoit SIGOURE wrote: >> FYI, I needed a replacement of `trunc' and `round' for >> mipsel-linux-g++-3.3.2 with newlib-1.10.0. > > Do you feel that newlib is an important platform? Would you be willin

Re: newlib platform

Benoit SIGOURE wrote: > FYI, I needed a replacement of `trunc' and `round' for mipsel-linux-g++-3.3.2 > with newlib-1.10.0. Do you feel that newlib is an important platform? Would you be willing to update all doc/functions/* files to mention those functions which are missing from newlib? (newlib-

Re: 0 vs. NULL (was: Re: Test for getaddrinfo() broken on Tru64 UNIX 5.1)

Ben Pfaff wrote: > ISO C says that NULL can be defined as 0, without a cast to void > *, and it is always defined that way in C++. The latter statement is not true. ISO C++ 18.1.(3) says: "The macro NULL is an implementation-defined C++ null pointer constant in this International Standard (4

Re: 0 vs. NULL (was: Test for getaddrinfo() broken on Tru64 UNIX 5.1)

Benoit SIGOURE wrote: > In C++, `0' is the preferred way of expressing `NULL'. In C++, 0 can be used instead of NULL everywhere except inside sizeof and varargs argument lists. But what is _preferred_, depends on your and your co-developers' habits. People who also program in C prefer NULL becau

Re: Test for getaddrinfo() broken on Tru64 UNIX 5.1

Bruno Haible <[EMAIL PROTECTED]> wrote: > Benoit SIGOURE wrote: >> > 4) Don't use 0 to designate null pointers. That doesn't sit well with >> > C++ compilers. >> >> s/C++/C/ right? > > Actually, neither C nor C++ compilers cry when you use 0 for NULL. It's only > my personal preference. I p

Re: Test for getaddrinfo() broken on Tru64 UNIX 5.1

Simon Josefsson <[EMAIL PROTECTED]> writes: > On platforms where integers aren't the same size as pointers, things can > go wrong if 1) you pass 0 to a function that expects a pointer and no > function prototype was available during compilation, or 2) you pass it > to a function that takes a varia

Re: Test for getaddrinfo() broken on Tru64 UNIX 5.1

On Oct 13, 2007, at 9:34 PM, Simon Josefsson wrote: Bruno Haible <[EMAIL PROTECTED]> writes: Benoit SIGOURE wrote: 4) Don't use 0 to designate null pointers. That doesn't sit well with C++ compilers. s/C++/C/ right? Actually, neither C nor C++ compilers cry when you use 0 for NUL

Re: Gnulib needed in AC_CHECK_HEADERS

Sylvain Beucler wrote: > I'm cross-compiling an SDL application for i586-mingw32mscv. I > imported the alloca module from Gnulib, as a dependency of strcasestr. You mean the 'alloca-opt' module, I guess? > When checking for SDL.h, > > AC_CHECK_HEADERS(SDL.h SDL_rotozoom.h SDL_framerate.h SDL_

Re: Test for getaddrinfo() broken on Tru64 UNIX 5.1

Bruno Haible <[EMAIL PROTECTED]> writes: > Benoit SIGOURE wrote: >> > 4) Don't use 0 to designate null pointers. That doesn't sit well with >> > C++ compilers. >> >> s/C++/C/ right? > > Actually, neither C nor C++ compilers cry when you use 0 for NULL. It's only > my personal preference.

Re: Test for getaddrinfo() broken on Tru64 UNIX 5.1

Benoit SIGOURE wrote: > > 4) Don't use 0 to designate null pointers. That doesn't sit well with > > C++ compilers. > > s/C++/C/ right? Actually, neither C nor C++ compilers cry when you use 0 for NULL. It's only my personal preference. Bruno

Re: Test for getaddrinfo() broken on Tru64 UNIX 5.1

Bruno Haible <[EMAIL PROTECTED]> writes: > Hi Albert, > > Simon has not taken this up in 3 days, so I'm doing it. Thanks! Your patch looks fine to me. /Simon

Re: Fwd: Re: error.c: "Unknown system error" should report errno value (fwd)

Martin Koeppe wrote: > The relevant output is done by asprintf(). And by printf() in line 269. That's it. coreutils needs to use also printf-posix, not only vasprintf-posix. Then 'seq' should work. Bruno

Re: Fwd: Re: error.c: "Unknown system error" should report errno value (fwd)

sorry, just noted that I forgot to add the list in reply... -- Forwarded message -- Date: Tue, 9 Oct 2007 09:49:29 +0200 (CEST) From: Martin Koeppe To: Bruno Haible Subject: Re: Fwd: Re: error.c: "Unknown system error" should report errno value On Tue, 9 Oct 2007, Bruno Haible

Re: Test for getaddrinfo() broken on Tru64 UNIX 5.1

On Oct 13, 2007, at 4:25 PM, Bruno Haible wrote: 4) Don't use 0 to designate null pointers. That doesn't sit well with C++ compilers. s/C++/C/ right? -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part

Re: Test for getaddrinfo() broken on Tru64 UNIX 5.1

Hi Albert, Simon has not taken this up in 3 days, so I'm doing it. Albert Chin wrote: > m4/getaddrinfo.m4 tests for getaddrinfo with: > AC_CHECK_FUNCS(getaddrinfo > > This assumes getaddrinfo is available on the system under the name > `getaddrinfo'. Not so on Tru64 UNIX 5.1 where has: > #i

Re: extern inline problem with argp when building tar 1.19 with GCC 4.2.1

Addendum to last patch: When __GNUC_STDC_INLINE__ is defined, we know that the compiler supports both the ISO C99 and the old GNU C semantics for 'inline'. In ten years, people will wonder "what was this old GNU C semantics". So it's better to use the ISO C99 semantics for the long-term use. 2007-

Re: [Bug-tar] GNU tar 1.19 on HP-UX

On Fri, 12 Oct 2007 17:35:14 -0700, Paul Eggert <[EMAIL PROTECTED]> wrote: > Re : > > Thanks for reporting those problems. The CHAR_BIT bug should have > been fixed by the patch in >

Re: extern inline problem with argp when building tar 1.19 with GCC 4.2.1

Hi Paul, > 2007-10-12 Paul Eggert <[EMAIL PROTECTED]> > > * lib/argp-fmtstream.h (ARGP_FS_EI): Work around GCC 4.2.1 diagnostic > "warning: C99 inline functions are not supported; using GNU89". This does not fix all warnings. I still get these warnings (on SuSE Linux 9.0, gcc 4.2.1

use __freading in glibc 2.7

The __freading behaviour in glibc has been fixed for glibc 2.7, including a unit test that verifies this behaviour. So, it's safe to use this glibc function now. 2007-10-13 Bruno Haible <[EMAIL PROTECTED]> * lib/freading.h (freading): Enable the use of __freading for glibc >= 2.