Re: strings.h in argz.c?
* Paul Eggert wrote on Mon, Jan 22, 2007 at 03:22:51AM CET: My experience is that everyone who's reported a bug against SunOS 4.1.x for several years, is either (1) doing it only because they're worried we might still want to be portable to SunOS 4.1.x, or (2) maintaining a computer museum. Neither of these cases are worth worrying about. OK. Ralf Wildenhues [EMAIL PROTECTED] writes: Is it likely (in practice) to have math functions like sin, cos, available but not math.h? Similarly, is it likely to have string functions but not string.h? Not these days, no. However it is possible that a freestanding environment would have neither math.h nor the math functions. PalmOS is one fairly-contemporary example. It's less likely for string.h to be missing (PalmOS has it, albeit in a shim mode if memory serves). OK, that's good enough for Libtool. If a test fails due to missing math.h, I won't be worried, if it would fail later anyway due to a missing sine function. * Simon Josefsson wrote on Mon, Jan 22, 2007 at 08:53:37AM CET: Ralf Wildenhues [EMAIL PROTECTED] writes: We got a bug report about Libtool 1.5.22 and SunOS 4.1.x this year, so I'm not doing any C89 cleanup on branch-1-5. That's not a problem, I only meant it to apply to future version. (I assume there will be future versions not based on branch-1-5 ;-)). I do hope so, too. OTOH, the change may eventually cause 2 less header checks in user code; that is, once all other checks for string.h and strings.h are eliminated from their configury. Yes, and another problem might be code that checks for strings.h and/or memory.h, but not string.h. It seems they might get the wrong headers.. Well, currently, Autoconf's _AC_INCLUDES_DEFAULT_REQUIREMENTS still tests for these anyway. I don't know about math.h. Math functions seem generally more optional than other functions to me, depending on platform. If your patch only changed this for the self tests, that is probably OK, but it seems weird for libtool/ltdl to require math functions. ACK. Only the test suite requires them. I applied the patch, with a NEWS bit added, to HEAD. Cheers, Ralf Assume C89 for included headers, and throughout the testsuite. * NEWS: Update. * libltdl/argz.c: Do not include strings.h nor memory.h, include string.h unconditionally. Patch by Simon Josefsson [EMAIL PROTECTED]. * libltdl/libltdl/lt__private.h: Likewise. * libltdl/m4/ltdl.m4 (LTDL_INIT): Do not check for string.h, strings.h, memory.h. * tests/cdemo/configure.ac: Assume presence of math.h. * tests/cdemo/foo.c: Likewise. * tests/demo/configure.ac: Likewise for math.h, string.h. Assume 'const'. Drop obsolete AC_EXEEXT. * tests/demo/dlmain.c: Likewise. * tests/demo/foo.c: Likewise. * tests/depdemo/configure.ac: Likewise. * tests/depdemo/l4/l4.c: Likewise. * tests/f77demo/configure.ac: Likewise. Also drop obsolete AC_OBJEXT. * tests/fcdemo/configure.ac: Likewise. * tests/mdemo/configure.ac: Likewise. * tests/mdemo/foo1.c: Likewise. * tests/mdemo/foo2.c: Likewise. * tests/mdemo2/configure.ac: Likewise. * tests/pdemo/configure.ac: Likewise. * tests/pdemo/longer_file_name_dlmain.c: * tests/pdemo/longer_file_name_foo.c: Likewise. * tests/pdemo/longer_file_name_foo2.c: Likewise. * tests/tagdemo/configure.ac: Likewise. * tests/tagdemo/foo.cpp: Likewise. Index: NEWS === RCS file: /cvsroot/libtool/libtool/NEWS,v retrieving revision 1.197 diff -u -r1.197 NEWS --- NEWS24 Oct 2006 20:17:37 - 1.197 +++ NEWS27 Jan 2007 16:44:19 - @@ -36,6 +36,9 @@ * Initial support for the Sun compiler suite on GNU/Linux. * Improved support for GNU/kFreeBSD and GNU/NetBSD. * Search paths with GCC on multilib systems like x86_64 have been fixed. +* The Libtool and libltdl macros and the testsuite now assume a C89 + environment, consequently do not test for headers such as string.h, + strings.h, memory.h any more. * Bug fixes. New in 1.9f: 2004-10-23; CVS version 1.9e, Libtool team: ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: strings.h in argz.c?
Ralf Wildenhues [EMAIL PROTECTED] writes: We got a bug report about Libtool 1.5.22 and SunOS 4.1.x this year, so I'm not doing any C89 cleanup on branch-1-5. That's not a problem, I only meant it to apply to future version. (I assume there will be future versions not based on branch-1-5 ;-)). OTOH, the change may eventually cause 2 less header checks in user code; that is, once all other checks for string.h and strings.h are eliminated from their configury. Yes, and another problem might be code that checks for strings.h and/or memory.h, but not string.h. It seems they might get the wrong headers.. I don't know about math.h. Math functions seem generally more optional than other functions to me, depending on platform. If your patch only changed this for the self tests, that is probably OK, but it seems weird for libtool/ltdl to require math functions. WDYT? ... * libltdl/argz.c: Do not include strings.h nor memory.h, include string.h unconditionally. Patch by Simon Josefsson [EMAIL PROTECTED]. I like this part. :-) Thanks, Simon ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: strings.h in argz.c?
Hello Simon, Apologies for the long delay. * Simon Josefsson wrote on Mon, Oct 30, 2006 at 01:46:30PM CET: Bruno Haible [EMAIL PROTECTED] writes: Is strings.h needed on any modern platform? No. I see that argz.c comes from libtool. Would this patch be acceptable? I'm cc:ing bug-libtool in case they have some legacy priority that demand strings.h. We got a bug report about Libtool 1.5.22 and SunOS 4.1.x this year, so I'm not doing any C89 cleanup on branch-1-5. * Bruno Haible wrote on Mon, Oct 30, 2006 at 03:06:54PM CET: Simon Josefsson wrote: I assume that memory.h is a side-effect of using strings.h, and that memory.h is not needed today either? Yes. Even on older systems like Solaris 2.4, AIX 4.3, IRIX 6.5, HP-UX 11, OSF/1 4.0, the contents of memory.h is also available through string.h. Thanks. Here's a quick audit of Libtool CVS HEAD to assume more of C89. I'm really not sure whether I should apply it: the mere prospect of lessening testsuite exposure on older hosts seems to me that it could easily be more of a problem than the few, half a decade old lines that nobody has needed to touch in a long time. OTOH, the change may eventually cause 2 less header checks in user code; that is, once all other checks for string.h and strings.h are eliminated from their configury. WDYT? Cheers, Ralf 2007-01-21 Ralf Wildenhues [EMAIL PROTECTED] Assume C89. * libltdl/argz.c: Do not include strings.h nor memory.h, include string.h unconditionally. Patch by Simon Josefsson [EMAIL PROTECTED]. * libltdl/libltdl/lt__private.h: Likewise. * libltdl/m4/ltdl.m4 (LTDL_INIT): Do not check for string.h, strings.h, memory.h. * tests/cdemo/configure.ac: Assume presence of math.h. * tests/cdemo/foo.c: Likewise. * tests/demo/configure.ac: Likewise for math.h, string.h. Assume 'const'. Drop obsolete AC_EXEEXT. * tests/demo/dlmain.c: Likewise. * tests/demo/foo.c: Likewise. * tests/depdemo/configure.ac: Likewise. * tests/depdemo/l4/l4.c: Likewise. * tests/f77demo/configure.ac: Likewise. Also drop obsolete AC_OBJEXT. * tests/fcdemo/configure.ac: Likewise. * tests/mdemo/configure.ac: Likewise. * tests/mdemo/foo1.c: Likewise. * tests/mdemo/foo2.c: Likewise. * tests/mdemo2/configure.ac: Likewise. * tests/pdemo/configure.ac: Likewise. * tests/pdemo/longer_file_name_dlmain.c: * tests/pdemo/longer_file_name_foo.c: Likewise. * tests/pdemo/longer_file_name_foo2.c: Likewise. * tests/tagdemo/configure.ac: Likewise. * tests/tagdemo/foo.cpp: Likewise. Index: libltdl/argz.c === RCS file: /cvsroot/libtool/libtool/libltdl/argz.c,v retrieving revision 1.9 diff -u -r1.9 argz.c --- libltdl/argz.c 24 Oct 2006 20:33:38 - 1.9 +++ libltdl/argz.c 21 Jan 2007 15:49:45 - @@ -1,5 +1,5 @@ /* argz.c -- argz implementation for non-glibc systems - Copyright (C) 2004, 2006 Free Software Foundation, Inc. + Copyright (C) 2004, 2006, 2007 Free Software Foundation, Inc. Originally by Gary V. Vaughan [EMAIL PROTECTED] NOTE: The canonical source of this file is maintained with the @@ -40,15 +40,7 @@ #include stdlib.h #include sys/types.h #include errno.h - -#if defined(HAVE_STRING_H) -# include string.h -#elif defined(HAVE_STRINGS_H) -# include strings.h -#endif -#if defined(HAVE_MEMORY_H) -# include memory.h -#endif +#include string.h #define EOS_CHAR '\0' Index: libltdl/libltdl/lt__private.h === RCS file: /cvsroot/libtool/libtool/libltdl/libltdl/lt__private.h,v retrieving revision 1.10 diff -u -r1.10 lt__private.h --- libltdl/libltdl/lt__private.h 26 Oct 2006 20:39:04 - 1.10 +++ libltdl/libltdl/lt__private.h 21 Jan 2007 15:49:47 - @@ -1,5 +1,5 @@ /* lt__private.h -- internal apis for libltdl - Copyright (C) 2004, 2005, 2006 Free Software Foundation, Inc. + Copyright (C) 2004, 2005, 2006, 2007 Free Software Foundation, Inc. Originally by Gary V. Vaughan [EMAIL PROTECTED] NOTE: The canonical source of this file is maintained with the @@ -40,22 +40,12 @@ #include ctype.h #include assert.h #include errno.h +#include string.h #if defined(HAVE_UNISTD_H) # include unistd.h #endif -#if defined(HAVE_STRING_H) -# include string.h -#else -# if defined(HAVE_STRINGS_H) -#include strings.h -# endif -#endif -#if defined(HAVE_MEMORY_H) -# include memory.h -#endif - /* Import internal interfaces... */ #include lt__alloc.h #include lt__dirent.h Index: libltdl/m4/ltdl.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/ltdl.m4,v retrieving revision 1.30 diff -u -r1.30 ltdl.m4 --- libltdl/m4/ltdl.m4 25 Aug 2006 15:04:30 -
Re: strings.h in argz.c?
Ralf Wildenhues [EMAIL PROTECTED] writes: We got a bug report about Libtool 1.5.22 and SunOS 4.1.x this year, so I'm not doing any C89 cleanup on branch-1-5. this year meaning 2007? Or in the last 12 months? I searched for such a bug report and found only http://lists.gnu.org/archive/html/bug-libtool/2006-06/msg00021.html which mentions m68k SunOS 4.1.1 and sparc sunos 4.1.4. However, in http://lists.gnu.org/archive/html/bug-libtool/2006-06/msg00025.html you asked Does anybody actually use these systems outside of a museum?, noting that Sun itself dropped support for these operating systems long ago, and didn't get a response. I just checked http://www.sun.com/service/eosl/solaris/solaris_vintage_eol_5.2005.xml, and Sun stopped fixing bugs in SunOS 4.1.1 on 1997-01-06 and in SunOS 4.1.4 on 2000-09-30, and stopped giving advice about them on 2000-01-76 and 2003-09-30 respectively. Obviously it's up to you as to whether to do C89 cleanup, but if that bug report is what we're talking about, I wouldn't worry about it. On the other hand, is libtool supposed to address the problem of freestanding C compilers? If so, the only headers it is allowed to assume are float.h, limits.h, stdarg.h, and stddef.h. If memory serves, gnulib sometimes assumes freestanding, but more often hosted. ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: strings.h in argz.c?
Hi! I have had a patch for argz.c sitting in my local gnulib tree for a while, discussed on the bug-gnulib list some time ago. It seems as if special string.h vs strings.h handling is not needed any more. Argz is the only remaining module in gnulib which still includes the header. See the discussion below. Would you consider installing the patch below in libtool? Thanks, Simon Simon Josefsson [EMAIL PROTECTED] writes: Bruno Haible [EMAIL PROTECTED] writes: Simon Josefsson wrote: #if defined(HAVE_STRING_H) # include string.h #elif defined(HAVE_STRINGS_H) # include strings.h #endif #if defined(HAVE_MEMORY_H) # include memory.h #endif Is strings.h needed on any modern platform? No. 1) string.h exists on all platforms, for several years now. The #elif branch in the above code is therefore never executed. 2) There are a few other functions defined in glibc strings.h, but they are not useful. See http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00113.html I assume that memory.h is a side-effect of using strings.h, and that memory.h is not needed today either? I see that argz.c comes from libtool. Would this patch be acceptable? I'm cc:ing bug-libtool in case they have some legacy priority that demand strings.h. /Simon Index: argz.c === RCS file: /sources/gnulib/gnulib/lib/argz.c,v retrieving revision 1.8 diff -u -p -r1.8 argz.c --- argz.c 24 Oct 2006 20:40:29 - 1.8 +++ argz.c 3 Jan 2007 12:33:47 - @@ -32,15 +32,7 @@ #include stdlib.h #include sys/types.h #include errno.h - -#if defined(HAVE_STRING_H) -# include string.h -#elif defined(HAVE_STRINGS_H) -# include strings.h -#endif -#if defined(HAVE_MEMORY_H) -# include memory.h -#endif +#include string.h #define EOS_CHAR '\0' ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: strings.h in argz.c?
Bruno Haible [EMAIL PROTECTED] writes: Simon Josefsson wrote: #if defined(HAVE_STRING_H) # include string.h #elif defined(HAVE_STRINGS_H) # include strings.h #endif #if defined(HAVE_MEMORY_H) # include memory.h #endif Is strings.h needed on any modern platform? No. 1) string.h exists on all platforms, for several years now. The #elif branch in the above code is therefore never executed. 2) There are a few other functions defined in glibc strings.h, but they are not useful. See http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00113.html I assume that memory.h is a side-effect of using strings.h, and that memory.h is not needed today either? I see that argz.c comes from libtool. Would this patch be acceptable? I'm cc:ing bug-libtool in case they have some legacy priority that demand strings.h. /Simon --- argz.c 25 Oct 2006 13:16:14 +0200 1.8 +++ argz.c 30 Oct 2006 13:44:32 +0100 @@ -32,15 +32,7 @@ #include stdlib.h #include sys/types.h #include errno.h - -#if defined(HAVE_STRING_H) # include string.h -#elif defined(HAVE_STRINGS_H) -# include strings.h -#endif -#if defined(HAVE_MEMORY_H) -# include memory.h -#endif #define EOS_CHAR '\0' ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: strings.h in argz.c?
Simon Josefsson wrote: I assume that memory.h is a side-effect of using strings.h, and that memory.h is not needed today either? Yes. Even on older systems like Solaris 2.4, AIX 4.3, IRIX 6.5, HP-UX 11, OSF/1 4.0, the contents of memory.h is also available through string.h. Bruno ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool