Re: regex.c not 64-bit clean (?)
[EMAIL PROTECTED] (Eric Blake) writes: Bruno, is it okay to apply this? 2006-06-14 Eric Blake [EMAIL PROTECTED] * ssize_t.m4 (gt_TYPE_SSIZE_T): Work in spite of -Werror. I'm not Bruno, but yes, please apply that. Thanks.
Re: regex.c not 64-bit clean (?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 6/15/2006 1:32 AM: [EMAIL PROTECTED] (Eric Blake) writes: Bruno, is it okay to apply this? 2006-06-14 Eric Blake [EMAIL PROTECTED] * ssize_t.m4 (gt_TYPE_SSIZE_T): Work in spite of -Werror. Applied. I'm not Bruno, but yes, please apply that. Thanks. I asked, because I also had to break upstream sync with gettext, also applied: config/ChangeLog: 2006-06-15 Eric Blake [EMAIL PROTECTED] * srclist.txt (ssize_t.m4): Lose sync. - -- 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 iD8DBQFEkUw/84KuGfSFAYARAn2yAKC81LNTW4z5PiD39jtmx40ko0nBCACgnkYS 5WebLBf/ZOwlfbbf19K4uDM= =wabP -END PGP SIGNATURE- Index: config/srclist.txt === RCS file: /sources/gnulib/gnulib/config/srclist.txt,v retrieving revision 1.126 diff -u -p -r1.126 srclist.txt --- config/srclist.txt 30 May 2006 23:56:35 - 1.126 +++ config/srclist.txt 15 Jun 2006 11:59:08 - @@ -87,7 +87,7 @@ $GETTEXT/gettext-runtime/m4/wchar_t.m4 $GETTEXT/gettext-runtime/m4/wint_t.m4 m4 $GETTEXT/gettext-tools/m4/sig_atomic_t.m4 m4 $GETTEXT/gettext-tools/m4/signalblocking.m4m4 -$GETTEXT/gettext-tools/m4/ssize_t.m4 m4 +#$GETTEXT/gettext-tools/m4/ssize_t.m4 m4 # new argp not in glibc yet --13feb06.
Re: regex.c not 64-bit clean (?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Santiago Vila on 6/15/2006 2:53 AM: We are getting closer: $ cd m4 $ ./configure CFLAGS=-Wall LOG-configure $ make CFLAGS='-Wall -Werror' LOG-make make[3]: Entering directory `/home/sanvila/tmp/m4/lib' gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c strnlen1.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c xalloc-die.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c exitfail.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c mbchar.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c regex.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c strcasecmp.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -Werror -c xmalloc.c rm -f libm4.a ar cru libm4.a strnlen1.o xalloc-die.o exitfail.o mbchar.o regex.o strcasecmp.o xmalloc.o ranlib libm4.a make[3]: Leaving directory `/home/sanvila/tmp/m4/lib' Yeah! the gnulib portion compiled error-free! I'll go ahead and commit my patch to convert m4 1.4.x to use gnulib, now that I have proof it makes a positive difference. I'll visit the other failures on m4-patches only; no need for further gnulib traffic, once the gnulib portion is clean. - -- 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 iD8DBQFEkU0K84KuGfSFAYARAjvsAJ9k0TZUR2eE0Qs9rMjpXWe3lfeFxACgmWPX IXjRK84mCoq7cVTpmo36vlU= =scCl -END PGP SIGNATURE-
Re: [Cvs-dev] Re: [Cvs-test-results] Build CVS (TRUNK) failed.
Hi Folks, The CVS project found a need to add the following patch to lib/strtoimax.c in order to get compilation on Windows to work. The basic problem is that there is an __int64 type and three conversion functions: char * _i64toa(__int64, char *, int); char * _ui64toa(unsigned __int64, char *, int); __int64 _atoi64(const char *); but 'long long' is NOT available. This means that HAVE_LONG_LONG is not defined and intmax_t is indeed __int64, so sizeof(INT) is greater than sizeof (long int). If you agree that the patch is reasonable, please install it. Thanks, -- Mark Index: strtoimax.c === RCS file: /cvsroot/cvs/ccvs/lib/strtoimax.c,v retrieving revision 1.3 diff -u -p -u -p -r1.3 strtoimax.c --- strtoimax.c 12 Jun 2006 02:33:47 - 1.3 +++ strtoimax.c 15 Jun 2006 16:50:09 - @@ -69,7 +69,7 @@ strtoimax (char const *ptr, char **endpt if (sizeof (INT) != sizeof (long int)) return strtoll (ptr, endptr, base); #else - verify (sizeof (INT) = sizeof (long int)); + verify (sizeof (INT) == sizeof (long int)); #endif return strtol (ptr, endptr, base);
Re: [Cvs-dev] Re: [Cvs-test-results] Build CVS (TRUNK) failed.
[Sorry about sending a reverse patch the first time around...] Hi Folks, The CVS project found a need to add the following patch to lib/strtoimax.c in order to get compilation on Windows to work. The basic problem is that there is an __int64 type and three conversion functions: char * _i64toa(__int64, char *, int); char * _ui64toa(unsigned __int64, char *, int); __int64 _atoi64(const char *); but 'long long' is NOT available. This means that HAVE_LONG_LONG is not defined and intmax_t is indeed __int64, so sizeof(INT) is greater than sizeof (long int). If you agree that the patch is reasonable, please install it. Thanks, -- Mark Index: strtoimax.c === RCS file: /sources/gnulib/gnulib/lib/strtoimax.c,v retrieving revision 1.14 diff -u -p -r1.14 strtoimax.c --- strtoimax.c 18 Apr 2006 17:20:47 - 1.14 +++ strtoimax.c 15 Jun 2006 17:47:10 - @@ -69,7 +69,7 @@ strtoimax (char const *ptr, char **endpt if (sizeof (INT) != sizeof (long int)) return strtoll (ptr, endptr, base); #else - verify (sizeof (INT) == sizeof (long int)); + verify (sizeof (INT) = sizeof (long int)); #endif return strtol (ptr, endptr, base);
Re: [Cvs-dev] Re: [Cvs-test-results] Build CVS (TRUNK) failed.
Mark D. Baushke [EMAIL PROTECTED] writes: but 'long long' is NOT available. That's weird, since it's been part of the C standard for 7 years. Are the Microsoft Windows C compilers that far behind the times? Or perhaps they just need to set some compiler switch to make 'long long' available? Or can you just ask them to upgrade to a recent-enough compiler? I vaguely recall that if they use Visual C++.NET 2002 or later, it should work. This means that HAVE_LONG_LONG is not defined and intmax_t is indeed __int64, so sizeof(INT) is greater than sizeof (long int). The patch is not reasonable by itself, since it will cause a 32-bit strtol to be used to implement what is supposed to be a 64-bit strtoimax. Hence you will get obscure errors at runtime if you use that patch to defeat the compile-time checking.
Re: [Cvs-dev] Re: [Cvs-test-results] Build CVS (TRUNK) failed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Eggert [EMAIL PROTECTED] writes: I'm getting a bit lost with info about both stdint.h versus inttypes.h, but does the following patch fix the problem? This does not fix the problem as the AC_CACHE_VAL(gl_cvs_header_stdint_h) is interfering with the test due to a previous use of this: AC_CHECK_HEADERS(\ ... stdint.h \ ... ) in configure.in Is this another case where another STDINT_H_BROKEN macro needs to be introduced similar to how inttypes-pri.m4 works? -- Mark 2006-06-12 Paul Eggert [EMAIL PROTECTED] * m4/stdint.m4 (gl_STDINT_H): Reject stdint.h if it doesn't declare intmax_t. Problem reported by Larry Jones and Derek Price in http://lists.gnu.org/archive/html/bug-gnulib/2006-06/msg00030.html. --- old/m4/stdint.m4 2006-01-09 05:20:01.0 -0800 +++ new/m4/stdint.m4 2006-06-12 09:25:44.0 -0700 @@ -17,7 +17,7 @@ AC_CHECK_HEADERS([sys/bitypes.h]) AC_MSG_CHECKING([for stdint.h]) AC_CACHE_VAL(gl_cv_header_stdint_h, [ - AC_TRY_COMPILE([#include stdint.h], [], + AC_TRY_COMPILE([#include stdint.h], [intmax_t i = -1; return i != 0;], gl_cv_header_stdint_h=yes, gl_cv_header_stdint_h=no)]) AC_MSG_RESULT([$gl_cv_header_stdint_h]) if test $gl_cv_header_stdint_h = yes; then -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEkfj4Cg7APGsDnFERApRjAKCDiBbmEjVJYYRrzFuMj6jonpvlKQCgmMas I3owY+tk/qMDmtMWT9y8Svg= =JPS3 -END PGP SIGNATURE-
Re: [Cvs-dev] Re: [Cvs-test-results] Build CVS (TRUNK) failed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Eggert wrote: Mark D. Baushke [EMAIL PROTECTED] writes: but 'long long' is NOT available. That's weird, since it's been part of the C standard for 7 years. Are the Microsoft Windows C compilers that far behind the times? PMFJI - I'm the one who originated the request. Partly that, and partly we are currently targeting an old compiler to begin with (it predates C99). Or perhaps they just need to set some compiler switch to make 'long long' available? Or can you just ask them to upgrade to a recent-enough compiler? I vaguely recall that if they use Visual C++.NET 2002 or later, it should work. This is a reasonable suggestion, after all the compiler is 8 years old. However it requires converting the project files and possibly updating a lot of the compiler options. Not an unreasonable thing to do, but it just means someone has to find time to do it. This means that HAVE_LONG_LONG is not defined and intmax_t is indeed __int64, so sizeof(INT) is greater than sizeof (long int). The patch is not reasonable by itself, since it will cause a 32-bit strtol to be used to implement what is supposed to be a 64-bit strtoimax. Hence you will get obscure errors at runtime if you use that patch to defeat the compile-time checking. Hmmm, yes, I had a closer look at the function and I see what you mean. OK, let me have another kick at this and see if I can come up with a better solution. - -- Jim Hyslop Dreampossible: Better software. Simply. http://www.dreampossible.ca Consulting * Mentoring * Training in C/C++ * OOD * SW Development Practices * Version Management -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEkh+TLdDyDwyJw+MRApegAJ4nUeochRTQknblUEfM0l+fB4hJvwCdHqpB BT695ubzNHO5ujBm2wXalvM= =nmAq -END PGP SIGNATURE-
