Re: on IRIX-5.3 & SGI-cc
Hi Martin,
The CVS project has forked from the GNULIB project slightly for the
stdint stuff as I have not seen any commit to gnulib to support the SGI
compilation problems we had observed. I have hopes that they will either
adopt our changes or equivalent changes so that we can once more use
their version directly.
Note: The BSDI BSD/OS 4.2 change has not yet been fully tested on a
BSD/OS 4.2 system to see if it fixes the problem. However, I suspect it
should work fine.
The lib/stdint.h which is generated on an IRIX 5.3 system should have
all of the stuff you need without any change needed to md5.c or md5.h.
If you want to checkout a copy of the vanilla CVS sources and do a quick
configure and build to let us know of any warnings or errors you see,
that could be very helpful.
We are nearing a public release of CVS 1.12.14, so anyone with oddball
versions of hardware and operating systems that have problems building
the current sources are urged to let us know what you have and if
possible what needs to be done to fix things.
Thanks,
-- Mark
--- GNULIB patched sources ---
ChangeLog:
* stdint_.h (__bsdos__): BSD/OS 4.2 needs to include
to avoid a generated that redifines
typedefs already found in .
(__sgi): For IRIX 5.3, the in c89 mode defines
all of the types needed while the for
uses #error in c89 mode. In c99 mode, includes
and defines all of the needed types.
Index: lib/stdint_.h
===
RCS file: /sources/gnulib/gnulib/lib/stdint_.h,v
retrieving revision 1.17
diff -u -p -r1.17 stdint_.h
--- lib/stdint_.h 17 Jun 2006 20:02:16 - 1.17
+++ lib/stdint_.h 23 Jun 2006 07:34:51 -
@@ -33,6 +33,11 @@
#if defined(__FreeBSD__) && (__FreeBSD__ >= 3) && (__FreeBSD__ <= 4)
# include
#endif
+#if defined(__bsdos__)
+ /* In BSD/OS 4.2, includes some of the needed typedefs
+ that would otherwise conflict with types in a generated . */
+# include
+#endif
#if defined(__OpenBSD__)
/* In OpenBSD 3.8, includes , which defines
int{8,16,32,64}_t, uint{8,16,32,64}_t and __BIT_TYPES_DEFINED__.
@@ -55,7 +60,7 @@
But note that contains only the type definitions! */
# include
#endif
-#if (defined(__hpux) || defined(_AIX)) && @HAVE_INTTYPES_H@
+#if (defined(__hpux) || defined(_AIX) || defined(__sgi)) && @HAVE_INTTYPES_H@
/* HP-UX 10 has nearly everything, except UINT_LEAST8_MAX,
UINT_FAST8_MAX, PTRDIFF_MIN, PTRDIFF_MAX. */
/* AIX 4 has nearly everything, except INTPTR_MIN, INTPTR_MAX,
@@ -64,7 +69,9 @@
#endif
#if @HAVE_STDINT_H@
/* Other systems may have an incomplete . */
-# include @FULL_PATH_STDINT_H@
+# if !defined(__sgi) || [EMAIL PROTECTED]@
+# include @FULL_PATH_STDINT_H@
+# endif
#endif
/* 7.18.1.1. Exact-width integer types */
Index: m4/stdint.m4
===
RCS file: /sources/gnulib/gnulib/m4/stdint.m4,v
retrieving revision 1.7
diff -u -p -r1.7 stdint.m4
--- m4/stdint.m419 Jun 2006 11:27:00 - 1.7
+++ m4/stdint.m423 Jun 2006 07:34:52 -
@@ -90,7 +90,7 @@ typedef int array [2 * (POW63 != 0 && PO
#if defined(__FreeBSD__) && (__FreeBSD__ >= 3) && (__FreeBSD__ <= 4)
# include
#endif
-#if defined(__OpenBSD__)
+#if defined(__OpenBSD__) || defined(__bsdos__)
# include
# if HAVE_INTTYPES_H
# include FULL_PATH_INTTYPES_H
@@ -102,11 +102,13 @@ typedef int array [2 * (POW63 != 0 && PO
#if defined(__sun) && HAVE_SYS_INTTYPES_H
# include
#endif
-#if (defined(__hpux) || defined(_AIX)) && HAVE_INTTYPES_H
+#if (defined(__hpux) || defined(_AIX) || defined(__sgi)) && HAVE_INTTYPES_H
# include FULL_PATH_INTTYPES_H
#endif
#if HAVE_STDINT_H
-# include FULL_PATH_STDINT_H
+# if !defined(__sgi) || !HAVE_INTTYPES_H
+# include FULL_PATH_STDINT_H
+# endif
#endif
'
gl_STDINT_CHECK_TYPES(
--- end of GNULIB patch ---
Re: small inet_ntop.m4 fix
On Wed, 2006-06-21 at 12:03 +0200, Simon Josefsson wrote: > Simon Josefsson <[EMAIL PROTECTED]> writes: > > > Yoann Vandoorselaere <[EMAIL PROTECTED]> writes: > > > >> On Sat, 2006-06-17 at 21:02 +0200, Simon Josefsson wrote: > >>> Hi Yoann! Ok to install this? Gnulib assumes that sys/types.h > >>> exists, and inet_ntop never tested HAVE_SYS_TYPES_H anyway. > >> > >> Hi Simon, > >> > >> Did you make sure that removing the sys/types.h requirement doesn't > >> break the build on some platform, like FreeBSD 4.x ? > > > > Hi! sys/types.h is still included by the source code, what I did was > > to remove the autoconf test for sys/types.h, because the > > HAVE_SYS_TYPES_H CPP symbol wasn't used and isn't needed. > > > > Gnulib assumes that sys/types.h exists on all platforms, so we > > shouldn't test for it. > > Hi Yoann, are you happy with my explanation? Do you see any other > problem with this patch? Hi Simon, Yes, please go ahead. Regards, -- Yoann Vandoorselaere | Responsable R&D / CTO | PreludeIDS Technologies Tel: +33 (0)8 70 70 21 58 Fax: +33(0)4 78 42 21 58 http://www.prelude-ids.com
Re: [bug-gnulib] system module?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Andreas Büning on 6/22/2006 1:29 PM:
>
> However, I thought that this behaviour of system() was common on DOS/Win*/OS/2
> systems.
> system("xcopy non_existing_file") returns 1 for example.
That's not a problem, unless:
FILE*f;
int result;
int ch;
f = popen("xcopy non_existing_file", "r");
while ((ch = getc(f)) != EOF);
result = pclose(f);
returns 256, and if WEXITSTATUS is defined as (status>>8)&0xff. Can
someone with mingw access confirm if this system() bug is widespread?
I've already checked that cygwin is not affected.
>
> Possibly, djgpp for DOS or the MinGW environment for Win* might have
> the same behaviour which I cannot test because I don't use them.
If they do, then I will try to write a module that does an AC_RUN_IFELSE
using something similar to the above; compare the results of popen and
system on the same command known to fail without producing output, and see
if the return values are the same.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEm+Eo84KuGfSFAYARAhhqAJ0Sy8AGeGhQGTdJ9ek5Xn8/V7CsGQCdGSP1
ulSMc2Efc8vdQqkZpYme4FU=
=Fl5W
-END PGP SIGNATURE-
Re: [bug-gnulib] system module?
Eric Blake asked:
> Is it worth adding a system module to gnulib that detects implementations
> with
> this bug, and provides rpl_system to work around it?
The specification of system() in ISO C 99 does not specify
1) which is the command processor,
and in particular which are the built-in commands and how to quote
arguments when constructing a program incovcation with arguments,
2) how the command is executed (in particular, the signal handling),
3) the return value semantics.
Andreas Büning asks about the third problem, but the first and second are
more important.
Because of 1), I don't think it would be useful for gnulib to provide a
substitute. When a programmer uses the system() command, you don't know
whether he intends to invoke the system's command processor or a /bin/sh
implementation. On Windows: cmd.exe or /bin/sh? On VMS: DCL or sh?
gnulib makes it easy to invoke /bin/sh on all platforms:
execute ("sh", "/bin/sh", { "/bin/sh", "-c", command, NULL }, ...)
We cannot provide portability aids for programmers who want to use
cmd.exe or DCL.
Witness of this: GNU clisp offers facilities for invoking programs and
executing commands, but does not use system(). IIRC, it used system()
15 years ago, but
1) the confusion between COMMAND.COM and CMD.EXE on DOS and Windows,
as well as the weird argument quoting rules on Windows, that are
different in CMD.EXE than in CreateProcess,
2) the signal handling on SVR4 systems,
and some additional problem with file descriptors in EMX system(),
made it unpractical to continue using system(). (I don't remember the
details, sorry.)
Bruno
Re: [bug-gnulib] Re: result type of INT16_C, UINT16_C
Ben Pfaff wrote: > I think you are overlooking the changes in Technical Corrigendum > 1, which includes the following: Thanks for the text; I don't have a copy of this Technical Corrigendum. I have changed stdint_.h and the test module accordingly. Bruno diff -c -3 -r1.17 stdint_.h *** lib/stdint_.h 17 Jun 2006 20:02:16 - 1.17 --- lib/stdint_.h 23 Jun 2006 14:54:37 - *** *** 924,944 #if !defined(__cplusplus) || defined(__STDC_CONSTANT_MACROS) /* 7.18.4.1. Macros for minimum-width integer constants */ #undef INT8_C #undef UINT8_C #define INT8_C(x) x ! #define UINT8_C(x) x##U #undef INT16_C #undef UINT16_C #define INT16_C(x) x ! #define UINT16_C(x) x##U #undef INT32_C #undef UINT32_C #define INT32_C(x) x ! #define UINT32_C(x) x##U #undef INT64_C #undef UINT64_C --- 924,969 #if !defined(__cplusplus) || defined(__STDC_CONSTANT_MACROS) /* 7.18.4.1. Macros for minimum-width integer constants */ + /* According to ISO C 99 Technical Corrigendum 1 */ #undef INT8_C #undef UINT8_C #define INT8_C(x) x ! #if @HAVE_UINT8_T@ ! # if @BITSIZEOF_UINT8_T@ < @BITSIZEOF_UNSIGNED_INT@ ! # define UINT8_C(x) x ! # else ! # define UINT8_C(x) x##U ! # endif ! #else ! # define UINT8_C(x) x ! #endif #undef INT16_C #undef UINT16_C #define INT16_C(x) x ! #if @HAVE_UINT16_T@ ! # if @BITSIZEOF_UINT16_T@ < @BITSIZEOF_UNSIGNED_INT@ ! # define UINT16_C(x) x ! # else ! # define UINT16_C(x) x##U ! # endif ! #else ! # define UINT16_C(x) x ! #endif #undef INT32_C #undef UINT32_C #define INT32_C(x) x ! #if @HAVE_UINT32_T@ ! # if @BITSIZEOF_UINT32_T@ < @BITSIZEOF_UNSIGNED_INT@ ! # define UINT32_C(x) x ! # else ! # define UINT32_C(x) x##U ! # endif ! #else ! # define UINT32_C(x) x ! #endif #undef INT64_C #undef UINT64_C diff -c -3 -r1.1 test-stdint.c *** tests/test-stdint.c 16 Jun 2006 13:29:04 - 1.1 --- tests/test-stdint.c 23 Jun 2006 14:54:37 - *** *** 322,362 /* 7.18.4. Macros for integer constants */ verify (INT8_C (17) == 17); ! #if 0 /* The language in ISO C 99 7.18.4 is too strong. */ ! verify_same_types (INT8_C (17), (int_least8_t)0); ! #endif verify (UINT8_C (17) == 17); ! #if 0 /* The language in ISO C 99 7.18.4 is too strong. */ ! verify_same_types (UINT8_C (17), (uint_least8_t)0); ! #endif verify (INT16_C (17) == 17); ! #if 0 /* The language in ISO C 99 7.18.4 is too strong. */ ! verify_same_types (INT16_C (17), (int_least16_t)0); ! #endif verify (UINT16_C (17) == 17); ! #if 0 /* The language in ISO C 99 7.18.4 is too strong. */ ! verify_same_types (UINT16_C (17), (uint_least16_t)0); ! #endif verify (INT32_C (17) == 17); ! verify_same_types (INT32_C (17), (int_least32_t)0); verify (UINT32_C (17) == 17); ! verify_same_types (UINT32_C (17), (uint_least32_t)0); #if HAVE_INT_LEAST64_T_IN_STDINT_H || _STDINT_H_HAVE_INT64 verify (INT64_C (17) == 17); ! verify_same_types (INT64_C (17), (int_least64_t)0); #endif #if HAVE_UINT_LEAST64_T_IN_STDINT_H || _STDINT_H_HAVE_UINT64 verify (UINT64_C (17) == 17); ! verify_same_types (UINT64_C (17), (uint_least64_t)0); #endif verify (INTMAX_C (17) == 17); ! verify_same_types (INTMAX_C (17), (intmax_t)0); verify (UINTMAX_C (17) == 17); ! verify_same_types (UINTMAX_C (17), (uintmax_t)0); int --- 322,354 /* 7.18.4. Macros for integer constants */ verify (INT8_C (17) == 17); ! verify_same_types (INT8_C (17), (int_least8_t)0 + 0); verify (UINT8_C (17) == 17); ! verify_same_types (UINT8_C (17), (uint_least8_t)0 + 0); verify (INT16_C (17) == 17); ! verify_same_types (INT16_C (17), (int_least16_t)0 + 0); verify (UINT16_C (17) == 17); ! verify_same_types (UINT16_C (17), (uint_least16_t)0 + 0); verify (INT32_C (17) == 17); ! verify_same_types (INT32_C (17), (int_least32_t)0 + 0); verify (UINT32_C (17) == 17); ! verify_same_types (UINT32_C (17), (uint_least32_t)0 + 0); #if HAVE_INT_LEAST64_T_IN_STDINT_H || _STDINT_H_HAVE_INT64 verify (INT64_C (17) == 17); ! verify_same_types (INT64_C (17), (int_least64_t)0 + 0); #endif #if HAVE_UINT_LEAST64_T_IN_STDINT_H || _STDINT_H_HAVE_UINT64 verify (UINT64_C (17) == 17); ! verify_same_types (UINT64_C (17), (uint_least64_t)0 + 0); #endif verify (INTMAX_C (17) == 17); ! verify_same_types (INTMAX_C (17), (intmax_t)0 + 0); verify (UINTMAX_C (17) == 17); ! verify_same_types (UINTMAX_C (17), (uintmax_t)0 + 0); int
Re: on IRIX-5.3 & SGI-cc
This is making me more and more inclined to switch to a stdint.h replacement, not something that tries to augment existing broken systems. It would be much simpler to maintain, I think. I'll work on a proposal and try to have something ready in a day or two.
on IRIX-5.3 & SGI-cc
I'm not sure whether I should really chime in.
I'm mostly sending this stuff just because "What required for SGIs?"
w.r.t. stdint/inttypes has become a current topic and this fits in.
The recent gnulib stdint_.h changes for SGIs look promising to me.
However, it'll take some days for me to check them out. It's probably
silly but I just compiled these notes in the last days, so maybe I
should send them out now just as well. (Perhaps it serves as input
of some kind to someone, and IRIX-5.3 Indigos aren't exactly top-selling
machines these days...)
In March, I had major trouble to compile lib/md5.c, originating in
problems with stdint.h / inttypes.h. I was able to get it compile
cleanly in early April. (I also had to make three other, unrelated
fixes to te CVS sources.) I am confident that my setup gives the
definitions which I need but due to my lack of understanding of the
entire gnulib & autoconf architecture, I was not able to decide which
would be the clean tweaks. Then again, my (dirty!) tweaks turned out
to be just two little ones. I don't know how relevant to the current
discussion this still is. [Again: looks like the new "defined(__sgi)"
stuff just takes care of it, and in a proper way, too.]
This is CVS on a SGI Indigo (R3000, 32bit) running IRIX-5.3 and SGI's
commercial "IRIX Developer Option" cc (ANSI C as in ISO :1990 or
c89). I'm using -w2 which turns all warnings into serious errors
requiring some treatment (just like gcc -Werror does).
On this platform, the following SGI system headers exist:
: typedefs int{8,16,32}_t
: typedefs int{8,16,32,64}_t & unsigned counterparts
These two headerfiles are mutually exclusive. The comments in config.h
indicate this possible clash, and the autoconfiguration #defines neither
HAVE_INTTYPES_H nor HAVE_INTTYPES_H_WITH_UINTMAX (correctly, according
to the comments).
There is no on this platform.
My adjustments to get md5.c to compile were these:
(a) make the (generated) lib/stdint.h supply the missing "int64_t" and
all uintXX_t typedefs, but rely on int{8,16,32}_t coming from
SGI's .
(b) reorder the includes in md5.c so that SGI's
is included before md5.h indirectly includes the (generated)
gnulib-stdint.h (the latter really depends on ).
I append the (simple) diffs for (a) and (b) with following caveats:
(1) I _know_ my "_STDINT_H_NEED_SIGNED_INT_TYPES_XXX" renaming to achieve
purpose (a) above is a crude hack. (That's why it's "XXX".) My
only excuse is that I'm definitely too uninformed about both the
C standards and the gnulib/autoconf way of life to make any clever
decision about the placement/formulation of a proper fix.
(2) In the meantime, lib/stdint_.h has changed *a lot*, anyway.
[Like the new __sgi-dependent code I just see now.]
Having said this, it did the job. Maybe it serves as a tiny assist
to find the Right Thing for SGIs. I also have IRIX-6.5 R4400 + R10K
Indigo2s, but "only" with gcc, not the SGI compiler. I'm currently
extremely busy but if you think you can need more input, let me know.
Martin
Index: md5.c
===
RCS file: /sources/cvs/ccvs/lib/md5.c,v
retrieving revision 1.14
diff -u -r1.14 md5.c
--- md5.c 25 Jan 2006 12:53:38 - 1.14
+++ md5.c 22 Jun 2006 23:41:53 -
@@ -24,12 +24,13 @@
# include
#endif
+#include
+
#include "md5.h"
#include
#include
#include
-#include
#if USE_UNLOCKED_IO
# include "unlocked-io.h"
Index: stdint_.h
===
RCS file: /sources/cvs/ccvs/lib/stdint_.h,v
retrieving revision 1.7
diff -u -r1.7 stdint_.h
--- stdint_.h 30 Mar 2006 18:13:12 - 1.7
+++ stdint_.h 23 Jun 2006 02:08:32 -
@@ -65,7 +65,7 @@
# define _STDINT_H_HAVE_SYSTEM_INTTYPES
#endif
#if !((defined(UNIX_CYGWIN32) || defined(__linux__)) &&
defined(__BIT_TYPES_DEFINED__))
-# define _STDINT_H_NEED_SIGNED_INT_TYPES
+# define _STDINT_H_NEED_SIGNED_INT_TYPES_XXX
#endif
#if !defined(_STDINT_H_HAVE_SYSTEM_INTTYPES)
@@ -96,7 +96,7 @@
typedef unsigned long uint64_t;
#define _STDINT_H_HAVE_INT64
#elif @HAVE_LONG_LONG_64BIT@
-#ifdef _STDINT_H_NEED_SIGNED_INT_TYPES
+#ifdef _STDINT_H_NEED_SIGNED_INT_TYPES_XXX
typedef long long int64_t;
#endif
typedef unsigned long long uint64_t;
Re: on IRIX-5.3 & SGI-cc
> The lib/stdint.h which is generated on an IRIX 5.3 system should have > all of the stuff you need without any change needed to md5.c or md5.h. > > If you want to checkout a copy of the vanilla CVS sources and do a quick > configure and build to let us know of any warnings or errors you see, > that could be very helpful. I did a pristine checkout of HEAD (already containing the patches in your email), configured, and attempted to compile. Here is a very quick initial report. First observation: WINT_MIN and WINT_MAX are undefined. The Makefile/sed-substitions/stdint.h will substitute both @BITSIZEOF_WINT_T@ and @SAME_TYPE_WINT_T_LONG@ into an empty strings, turning this stdint_.h template fragment: /* wint_t limits */ #ifndef WINT_MIN # if @HAVE_SIGNED_WINT_T@ # if @BITSIZEOF_WINT_T@ > @BITSIZEOF_LONG@ || @SAME_TYPE_WINT_T_LONG@ # define WINT_MIN (-1L << (@BITSIZEOF_WINT_T@ - 1)) into this illegal stdint.h code: /* wint_t limits */ #ifndef WINT_MIN # if 0 # if > 32 || <=== flagged error here # define WINT_MIN (-1L << ( - 1))(<=== silently borked) # else (Three more following places in the "wint_t limits" section are affected just the same.) After hacking around this, I get much the same header conflicts as in March. Here is the error message for md5.c: source='md5.c' object='md5.o' libtool=no \ DEPDIR=.deps depmode=sgi /bin/ksh ../build-aux/depcomp \ cc -DHAVE_CONFIG_H -I. -I. -I.. -I../intl -Ino/include -w2 -g -c md5.c cfe: Error: /usr/include/sys/types.h, line 211: redeclaration of 'int8_t'; previous declaration at line 78 in file './stdint.h' typedefsigned char int8_t; ------ ^ cfe: Error: /usr/include/sys/types.h, line 212: redeclaration of 'int16_t'; previous declaration at line 86 in file './stdint.h' typedefshort int16_t; ---- ^ cfe: Error: /usr/include/sys/types.h, line 213: redeclaration of 'int32_t'; previous declaration at line 93 in file './stdint.h' typedef__int32_t int32_t; ---- ^ *** Error code 1 (bu21) Looks to me the issue is still unresolved. Martin
Re: [bug-gnulib] system module?
> Eric Blake asked:
> > Is it worth adding a system module to gnulib that detects
> implementations with
> > this bug, and provides rpl_system to work around it?
>
> The specification of system() in ISO C 99 does not specify
> 1) which is the command processor,
> and in particular which are the built-in commands and how to quote
> arguments when constructing a program incovcation with arguments,
> 2) how the command is executed (in particular, the signal handling),
> 3) the return value semantics.
But POSIX specifies all three points, so when implementing a POSIX version
of m4, it would be nice to rely on POSIX semantics of system(). I thought
one of gnulib's goals was to provide useful POSIX semantics atop
non-POSIX systems, where possible.
Also, C99 does not specify popen()/pclose(), but POSIX does. m4 has
been using system() to implement syscmd, and popen() to implement
esyscmd(). If system() is not worth using, then it is likely that popen()
should not be used, either.
>
> Andreas Büning asks about the third problem, but the first and second are
> more important.
Actually, Andreas was reporting that WEXITSTATUS was returning
the wrong value. But I just checked a mingw implementation
(actually, used the cygwin compiler in cross-compilation mode by
using -mno-cygwin), and found that popen() and system() are
consistent - the return value is in the lower 8 bits. And based on
this message, http://gcc.gnu.org/ml/fortran/2005-05/msg00225.html,
mingw still does not provide WEXITSTATUS in its headers (there is
no , and does not provide them), so my
fallback definitions of WEXITSTATUS (as recommended by the
autoconf manual under AC_CHECK_SYS_WAIT) were used instead,
explaining why it was grabbing the wrong 8 bits. If mingw had
instead provided WEXITSTATUS that grabbed the low 8 bits,
similar to BeOS, then this might have been a non-issue.
I have yet to get an answer from Andreas whether system() and
pclose() are consistent on OS/2, as they are on mingw, and whether
his system headers define WEXITSTATUS anywhere.
That thread means that the autoconf decision to obsolete
AC_HEADER_SYS_WAIT for 2.60 may have been premature; at
any rate, the documentation under that macro is not completely
accurate - I'll have to forward this bug report on to autoconf as
well.
>
> Because of 1), I don't think it would be useful for gnulib to provide a
> substitute. When a programmer uses the system() command, you don't know
> whether he intends to invoke the system's command processor or a /bin/sh
> implementation. On Windows: cmd.exe or /bin/sh? On VMS: DCL or sh?
> gnulib makes it easy to invoke /bin/sh on all platforms:
> execute ("sh", "/bin/sh", { "/bin/sh", "-c", command, NULL }, ...)
> We cannot provide portability aids for programmers who want to use
> cmd.exe or DCL.
What should m4 do in its syscmd() macro, then? POSIX is clear; if m4
is POSIX-compliant, then it executes the command using the POSIX
sh (not necessarily /bin/sh, but that serves as a close approximation).
But on non-POSIX platforms, such as mingw or OS/2, should syscmd
still expect the user to have /bin/sh available, rather than passing the
string to the native shell with all its non-portable quoting?
>
> Witness of this: GNU clisp offers facilities for invoking programs and
> executing commands, but does not use system(). IIRC, it used system()
> 15 years ago, but
> 1) the confusion between COMMAND.COM and CMD.EXE on DOS and Windows,
> as well as the weird argument quoting rules on Windows, that are
> different in CMD.EXE than in CreateProcess,
> 2) the signal handling on SVR4 systems,
> and some additional problem with file descriptors in EMX system(),
> made it unpractical to continue using system(). (I don't remember the
> details, sorry.)
>
> Bruno
--
View this message in context:
http://www.nabble.com/system-module--t1820214.html#a5014691
Sent from the Gnulib forum at Nabble.com.
Re: [bug-gnulib] system module?
Eric Blake wrote: > What should m4 do in its syscmd() macro, then? POSIX is clear; if m4 > is POSIX-compliant, then it executes the command using the POSIX > sh (not necessarily /bin/sh, but that serves as a close approximation). > But on non-POSIX platforms, such as mingw or OS/2, should syscmd > still expect the user to have /bin/sh available, rather than passing the > string to the native shell with all its non-portable quoting? This is a question that you (the m4 maintainers) have to answer. If you want m4 on mingw to call cmd.exe, then continue using the system() function, but please also document in the m4 documentation, node "Syscmd", that the argument on non-POSIX platforms is not a shell command. If you want m4 on mingw to call sh.exe, then you can use gnulib's 'execute' module, or contribute a posix_system() function that implements an invocation of "sh" including the POSIX-specified signal handling and return value. > I thought one of gnulib's goals was to provide useful POSIX semantics atop > non-POSIX systems, where possible. Yes. The particular point here is that not everyone will want posix_system(). There are valid uses of the system's system() function. Bruno
Re: [bug-gnulib] Re: result type of INT16_C, UINT16_C
Bruno Haible <[EMAIL PROTECTED]> writes: > Ben Pfaff wrote: >> I think you are overlooking the changes in Technical Corrigendum >> 1, which includes the following: > > Thanks for the text; I don't have a copy of this Technical Corrigendum. You can get a copy at iso.org for free. -- "Ho ho ho. I _so_ enjoy making a fool out of myself." --Linus, on Christmas Day, 2000
Re: Portablity bug in base64.c
Paul Eggert writes: > > That change is obviously safe, but why is it needed? Gnulib assumes > C89, and the preprocessors that you mention don't conform to C89. It isn't absolutely needed, but I'd argue that it's desirable. The cost of the change is exceeding low -- it doesn't make the code any harder to read or any less maintainable -- and it eliminates an essentially gratuitious incompatibility with a compiler that is otherwise perfectly acceptable. The big benefit is that it fixes the immediate problem now as opposed to waiting for the autoconf change to percolate out into the world. -Larry Jones Somebody's always running my life. I never get to do what I want to do. -- Calvin
Re: Portablity bug in base64.c
Since I don't assume I get the chance of saying this very often... * Larry Jones wrote on Fri, Jun 23, 2006 at 07:51:37PM CEST: > The big benefit is that it fixes the immediate problem now as opposed > to waiting for the autoconf change to percolate out into the world. ...this time the percolation latency will be about as low as it gets. :-) Cheers, Ralf
Re: Portablity bug in base64.c
Hi Ralf, ...this time the percolation latency will be about as low as it gets. :-) Likely so, OTOH, they are not bound together so folks will try to mix 'n match. :)
Re: Portablity bug in base64.c
Ralf Wildenhues writes: > > ...this time the percolation latency will be about as low as it gets. Only on your end. The bottleneck is usually at the other end of the pipeline. :-) -Larry Jones Physical education is what you learn from having your face in someone's armpit right before lunch. -- Calvin
Re: [bug-gnulib] system module?
Eric Blake-1 <[EMAIL PROTECTED]> writes: > That thread means that the autoconf decision to obsolete > AC_HEADER_SYS_WAIT for 2.60 may have been premature; at > any rate, the documentation under that macro is not completely > accurate - I'll have to forward this bug report on to autoconf as > well. That macro was intended only for the old BSD union wait problem. If you merely want to check for the existence of , your best bet is AC_CHECK_HEADER. > But on non-POSIX platforms, such as mingw or OS/2, should syscmd > still expect the user to have /bin/sh available, rather than passing the > string to the native shell with all its non-portable quoting? What do users on that platform want? If they don't know or don't care, the simplest would be to use a substitute implementation of 'system' that always returns 0. > I thought one of gnulib's goals was to provide useful POSIX > semantics atop non-POSIX systems, where possible. "Possible" is too strong. It would be more accurate to say "trivial".
Re: [bug-gnulib] gnulib-tool, sys_socket: don't steal mostlyclean-local
Simon Josefsson wrote: > The sys_socket module uses mostlyclean-local: > > mostlyclean-local: > -rmdir sys 2>/dev/null > > This makes it difficult for other modules to do the same. I get: > > Makefile:817: warning: overriding commands for target `mostlyclean-local' > Makefile:712: warning: ignoring old commands for target `mostlyclean-local' > > How about this solution? I agree about the problem. I committed a fix similar to yours, but that doesn't throw away stderr output. Bruno 2006-06-23 Simon Josefsson <[EMAIL PROTECTED]> Bruno Haible <[EMAIL PROTECTED]> * gnulib-tool (func_emit_lib_Makefile_am): Define MOSTLYCLEANDIRS. Emit mostlyclean-local rule. (func_emit_tests_Makefile_am): Likewise. * modules/sys_socket (Makefile.am): Use MOSTLYCLEANDIRS. diff -c -3 -r1.112 gnulib-tool *** gnulib-tool 9 May 2006 02:38:16 - 1.112 --- gnulib-tool 23 Jun 2006 19:26:18 - *** *** 749,754 --- 749,755 echo "BUILT_SOURCES =" echo "SUFFIXES =" echo "MOSTLYCLEANFILES =" + echo "MOSTLYCLEANDIRS =" echo "CLEANFILES =" echo "DISTCLEANFILES =" echo "MAINTAINERCLEANFILES =" *** *** 777,782 --- 778,791 fi done echo + echo "mostlyclean-local:" + echo " @test -z \"\$(MOSTLYCLEANDIRS)\" || \\" + echo "for dir in \$(MOSTLYCLEANDIRS); do \\" + echo " if test -d \$\$dir; then \\" + echo "echo \"rmdir \$\$dir\"; rmdir \$\$dir; \\" + echo " fi; \\" + echo "done" + echo echo "# Makefile.am ends here" } *** *** 818,823 --- 827,833 echo "BUILT_SOURCES =" echo "SUFFIXES =" echo "MOSTLYCLEANFILES =" + echo "MOSTLYCLEANDIRS =" echo "CLEANFILES =" echo "DISTCLEANFILES =" echo "MAINTAINERCLEANFILES =" *** *** 848,853 --- 858,871 echo "clean-local:" echo " rm -rf SunWS_cache" echo + echo "mostlyclean-local:" + echo " @test -z \"\$(MOSTLYCLEANDIRS)\" || \\" + echo "for dir in \$(MOSTLYCLEANDIRS); do \\" + echo " if test -d \$\$dir; then \\" + echo "echo \"rmdir \$\$dir\"; rmdir \$\$dir; \\" + echo " fi; \\" + echo "done" + echo echo "# Makefile.am ends here" } diff -c -3 -r1.2 sys_socket *** modules/sys_socket 19 Jun 2006 11:18:39 - 1.2 --- modules/sys_socket 23 Jun 2006 19:26:18 - *** *** 21,29 cp $(srcdir)/socket_.h [EMAIL PROTECTED] mv [EMAIL PROTECTED] $@ MOSTLYCLEANFILES += sys/socket.h sys/socket.h-t ! ! mostlyclean-local: ! -rmdir sys 2>/dev/null Include: #include --- 21,27 cp $(srcdir)/socket_.h [EMAIL PROTECTED] mv [EMAIL PROTECTED] $@ MOSTLYCLEANFILES += sys/socket.h sys/socket.h-t ! MOSTLYCLEANDIRS += sys Include: #include
Re: on IRIX-5.3 & SGI-cc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Marti, I have committed a change to CVS top-of-tree that may help you. Does your system protect against duplication of types out of ? -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEnD0ZCg7APGsDnFERAjXSAJ9YrwBHxlFCaZyz2RJSgLuMGJE5CQCbBwzt o0VicKMwKfhpB9TO7dd7D8g= =XJ0G -END PGP SIGNATURE-
Re: stdint module on SGI
Hi Mark,
Mark D. Baushke wrote:
> The following two patches take a closer step toward making things work
> under the default c89 compiler on SGI boxes.
Thanks for suggesting these. But IRIX 6.5 has the types defined
in and , therefore maybe some earlier
version of IRIX had them only in ? Therefore the appended
patch looks safer to me. I committed that.
> All files that #include still get warnings like this one:
>
> cc-1035 cc: WARNING File = /usr/include/stdint.h, Line = 5
> #error directive: This header file is to be used only for c99 mode
> compilations
>
> #error This header file is to be used only for c99 mode compilations
>^
>
> right now. It might be nice if just the existence of did not
> imply that it was useful to the compiler...
Well, that's not the case currently: I assume that when you check
for using autoconf's AC_CHECK_HEADERS, it will tell you that
the file exists? Hmm, is it nevertheless safe to leave this file aside
and do as you propose?
#if @HAVE_STDINT_H@
/* Other systems may have an incomplete . */
-# include @FULL_PATH_STDINT_H@
+# if !defined(__sgi) || [EMAIL PROTECTED]@
+# include @FULL_PATH_STDINT_H@
+# endif
#endif
> Given that a conforming C99 function is supposed to include
> , I wonder if it makes sense to try to only #include
> and see if that works before attempting to try to #include
> along with it.
" is supposed to include# ", but the reality is
different. was introduced several years earlier than
.
Bruno
diff -c -3 -r1.18 stdint_.h
*** lib/stdint_.h 23 Jun 2006 14:58:59 - 1.18
--- lib/stdint_.h 23 Jun 2006 20:52:19 -
***
*** 33,43
#if defined(__FreeBSD__) && (__FreeBSD__ >= 3) && (__FreeBSD__ <= 4)
# include
#endif
! #if defined(__OpenBSD__)
/* In OpenBSD 3.8, includes , which defines
int{8,16,32,64}_t, uint{8,16,32,64}_t and __BIT_TYPES_DEFINED__.
includes and also defines intptr_t and
uintptr_t. */
# include
# if @HAVE_INTTYPES_H@
# include @FULL_PATH_INTTYPES_H@
--- 33,45
#if defined(__FreeBSD__) && (__FreeBSD__ >= 3) && (__FreeBSD__ <= 4)
# include
#endif
! #if defined(__OpenBSD__) || defined(__sgi)
/* In OpenBSD 3.8, includes , which defines
int{8,16,32,64}_t, uint{8,16,32,64}_t and __BIT_TYPES_DEFINED__.
includes and also defines intptr_t and
uintptr_t. */
+ /* IRIX 6.5 has , and defines some of these
+ types as well. */
# include
# if @HAVE_INTTYPES_H@
# include @FULL_PATH_INTTYPES_H@
diff -c -3 -r1.7 stdint.m4
*** m4/stdint.m419 Jun 2006 11:27:00 - 1.7
--- m4/stdint.m423 Jun 2006 20:52:19 -
***
*** 1,4
! # stdint.m4 serial 7
dnl Copyright (C) 2001-2002, 2004-2006 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
--- 1,4
! # stdint.m4 serial 8
dnl Copyright (C) 2001-2002, 2004-2006 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
***
*** 90,96
#if defined(__FreeBSD__) && (__FreeBSD__ >= 3) && (__FreeBSD__ <= 4)
# include
#endif
! #if defined(__OpenBSD__)
# include
# if HAVE_INTTYPES_H
# include FULL_PATH_INTTYPES_H
--- 90,96
#if defined(__FreeBSD__) && (__FreeBSD__ >= 3) && (__FreeBSD__ <= 4)
# include
#endif
! #if defined(__OpenBSD__) || defined(__sgi)
# include
# if HAVE_INTTYPES_H
# include FULL_PATH_INTTYPES_H
Re: stdint module on SGI
Bruno Haible writes: > > Mark D. Baushke wrote: > > > > cc-1035 cc: WARNING File = /usr/include/stdint.h, Line = 5 > > #error directive: This header file is to be used only for c99 mode > > compilations > > > > #error This header file is to be used only for c99 mode compilations > >^ > > > > right now. It might be nice if just the existence of did not > > imply that it was useful to the compiler... > > Well, that's not the case currently: I assume that when you check > for using autoconf's AC_CHECK_HEADERS, it will tell you that > the file exists? It does -- since SGI chose to make #error just a warning, autoconf doesn't notice it. > Hmm, is it nevertheless safe to leave this file aside > and do as you propose? > > #if @HAVE_STDINT_H@ >/* Other systems may have an incomplete . */ > -# include @FULL_PATH_STDINT_H@ > +# if !defined(__sgi) || [EMAIL PROTECTED]@ > +# include @FULL_PATH_STDINT_H@ > +# endif > #endif It is. On SGI, once has been included, there's nothing to be gained by including as well. (The "|| [EMAIL PROTECTED]@" is probably specious since predates on SGI.) > " is supposed to include# ", but the reality is > different. was introduced several years earlier than > . But was created by extracting the language-related stuff from and requiring to include so that existing code would continue to get everything without having to include an additional header. Given that history, I would be very surprised to find a system where there's any benefit at all to including along with . If anyone knows of one, please speak up. -Larry Jones Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. -- Calvin
Re: stdint module on SGI
Hi Bruno,
The CVS forked version is getting closer to the GNULIB version.
(See below).
Bruno Haible <[EMAIL PROTECTED]> writes:
> Mark D. Baushke wrote:
> > The following two patches take a closer step toward making things work
> > under the default c89 compiler on SGI boxes.
>
> Thanks for suggesting these. But IRIX 6.5 has the types defined
> in and , therefore maybe some earlier
> version of IRIX had them only in ? Therefore the appended
> patch looks safer to me. I committed that.
Okay. The CVS sources need a further bit of
adjustment for both SGI IRIX 5.3 and BSDI BSD/OS
4.2. See the patch below.
> > All files that #include still get warnings like this one:
> >
> > cc-1035 cc: WARNING File = /usr/include/stdint.h, Line = 5
> > #error directive: This header file is to be used only for c99 mode
> > compilations
> >
> > #error This header file is to be used only for c99 mode compilations
> >^
> >
> > right now. It might be nice if just the existence of did not
> > imply that it was useful to the compiler...
>
> Well, that's not the case currently: I assume that when you check
> for using autoconf's AC_CHECK_HEADERS, it will tell you that
> the file exists?
Yes. It exists, but is useless for any c89
compilation. Also, since SGI makes #error just a
warning, autoconf is unable to figure out that the
file should never be included.
> Hmm, is it nevertheless safe to leave this file aside
> and do as you propose?
>
> #if @HAVE_STDINT_H@
>/* Other systems may have an incomplete . */
> -# include @FULL_PATH_STDINT_H@
> +# if !defined(__sgi) || [EMAIL PROTECTED]@
> +# include @FULL_PATH_STDINT_H@
> +# endif
> #endif
Yes. Larry suggests that the '|| [EMAIL PROTECTED]@'
may not be necessary, but I have a dim
recollection that IRIX 4.0 may not yet have had an
file, so that is was I was trying to
protect. I suspect that any recent vintage of SGI
box will have an and that this will
do the right thing in all cases.
> > Given that a conforming C99 function
> > is supposed to include
> > , I wonder if it makes sense to try
> > to only #include and see if that
> > works before attempting to try to #include
> > along with it.
>
> " is supposed to include# ", but the reality is
> different. was introduced several years earlier than
> .
Yes, and a conforming C99 file is
forced to #include . In fact, the SGI
IRIX 5.3 c99 compiler does have do
this. When c89 is used, the file is not included,
but all of the needed types are defined. Why they
did it in that manner is beyond my understanding.
-- Mark
2006-06-23 Larry Jones <[EMAIL PROTECTED]>
* stdint_.h: Try harder to find a definition of WCHAR_MIN/MAX.
Combine BSD/OS stuff with OpenBSD/SGI and use the correct
preprocessor symbol.
2006-06-23 Mark D. Baushke <[EMAIL PROTECTED]>
* stdint_.h: Both BSD/OS 4.2 and SGI-cc IRIX 5.3 seem to also need
included.
Index: lib/stdint_.h
===
RCS file: /sources/gnulib/gnulib/lib/stdint_.h,v
retrieving revision 1.19
diff -u -p -r1.19 stdint_.h
--- lib/stdint_.h 23 Jun 2006 20:52:39 - 1.19
+++ lib/stdint_.h 23 Jun 2006 22:08:50 -
@@ -26,6 +26,9 @@
/* Get wchar_t, WCHAR_MIN, WCHAR_MAX. */
#include
+#if !defined(WCHAR_MIN) && defined(HAVE_WCHAR_H)
+# include
+#endif
/* Get LONG_MIN, LONG_MAX, ULONG_MAX. */
#include
@@ -33,11 +36,13 @@
#if defined(__FreeBSD__) && (__FreeBSD__ >= 3) && (__FreeBSD__ <= 4)
# include
#endif
+#if defined(__OpenBSD__) || defined(__bsdi__) || defined(__sgi)
#if defined(__OpenBSD__) || defined(__sgi)
/* In OpenBSD 3.8, includes , which defines
int{8,16,32,64}_t, uint{8,16,32,64}_t and __BIT_TYPES_DEFINED__.
includes and also defines intptr_t and
uintptr_t. */
+ /* BSD/OS 4.2 is similar, but doesn't have */
/* IRIX 6.5 has , and defines some of these
types as well. */
# include
@@ -66,7 +71,9 @@
#endif
#if @HAVE_STDINT_H@
/* Other systems may have an incomplete . */
-# include @FULL_PATH_STDINT_H@
+# if !defined(__sgi) || [EMAIL PROTECTED]@
+# include @FULL_PATH_STDINT_H@
+# endif
#endif
/* 7.18.1.1. Exact-width integer types */
Index: m4/stdint.m4
===
RCS file: /sources/gnulib/gnulib/m4/stdint.m4,v
retrieving revision 1.8
diff -u -p -r1.8 stdint.m4
--- m4/stdint.m423 Jun 2006 20:52:39 - 1.8
+++ m4/stdint.m423 Jun 2006 22:08:50 -
@@ -90,7 +90,7 @@ typedef int array [2 * (POW63 != 0 && PO
#if defined(__FreeBSD__) && (__FreeBSD__ >= 3) && (__FreeBSD__ <= 4)
# include
#endif
-#if defined(__OpenBSD__) || defined(__sgi)
+#if defined(__OpenBSD__) || defined(__bsdi__) || defined(__sgi)
# include
# if HAVE_INTTYPES_H
# include FULL_PATH_INTTYPES_H
@@ -106,7 +106,9 @@ typedef int array [2 * (POW63 != 0 && PO
# include FULL_PATH_INTTYPES_H
#endif
#if HAVE_STD
Re: on IRIX-5.3 & SGI-cc
> Does your system protect against duplication of > types out of ? No. Neither that nor in the other direction. The conflicting (or rather: duplicated) typedefs are also not under control of any conditional such as __STDC__ or whatever. Both headers have the usual #ifndef brackets protecting against errors from repeated #inclusion. The labels used for this are: _SYS_TYPES_H __inttypes_INCLUDED Martin
Re: stdint module on SGI
Mark D. Baushke writes: > > > > #if @HAVE_STDINT_H@ > >/* Other systems may have an incomplete . */ > > -# include @FULL_PATH_STDINT_H@ > > +# if !defined(__sgi) || [EMAIL PROTECTED]@ > > +# include @FULL_PATH_STDINT_H@ > > +# endif > > #endif > > Yes. Larry suggests that the '|| [EMAIL PROTECTED]@' > may not be necessary, but I have a dim > recollection that IRIX 4.0 may not yet have had an > file, so that is was I was trying to > protect. But in that case it won't have a file, either, so the outer #if won't be satisfied (unless I'm misunderstanding how it's supposed to work). > In fact, the SGI > IRIX 5.3 c99 compiler does have do > this. When c89 is used, the file is not included, > but all of the needed types are defined. Why they > did it in that manner is beyond my understanding. Mine, too. I used to know some of the people in the SGI and Cray compiler groups, and they were quite sharp. I can only assume they've all left, because there's ample evidence of a serious clue shortage there now. :-) -Larry Jones It's hard to be religious when certain people are never incinerated by bolts of lightning. -- Calvin
