Re: i guess we're frozen & stuff
Today's the 10th, we release on the 15th, ergo we're frozen. What does this mean? Well I think the dilly is that we shouldn't be pushing to master, except to fix things that don't work at all, and to update documentation, NEWS, etc. What if you don't have push access? Well give Guile a try with your programs, run some benchmarks against 1.9.1, give the tires a good kick. Sorry, I've been distracted. Is this what we call 'master', and what I am running autobuilds against, along with the 1.8 branch? I will try to find time to install libunistring and get it to build. Have there been recent reports of success of 1.9.x on platforms other than GNU/Linux? Guile has been quite portable in the past and it's surely still very close if not there, and it would be a shame if 2.0 had issues. I realize this is hard for people to test if they don't have the platform, but it would be really good to have testing on at least one normal BSD and also Darwin. pgpSz7XBuXZnh.pgp Description: PGP signature
Re: i guess we're frozen & stuff
I built libunistring and tried to build master. Some tests failed, and also the build failed due to warnings (post to follow). I think all the failed tests are locale related. "gmake check" output on NetBSD/amd64 5.0 with libunistring 0.9.1: Making check in lib gmake[1]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/lib' gmake check-recursive gmake[2]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/lib' gmake[3]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/lib' gmake[3]: Nothing to be done for `check-am'. gmake[3]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/lib' gmake[2]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/lib' gmake[1]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/lib' Making check in meta gmake[1]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/meta' gmake[1]: Nothing to be done for `check'. gmake[1]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/meta' Making check in libguile gmake[1]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/libguile' gmake check-am gmake[2]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/libguile' gmake[2]: Nothing to be done for `check-am'. gmake[2]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/libguile' gmake[1]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/libguile' Making check in guile-readline gmake[1]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/guile-readline' gmake check-recursive gmake[2]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/guile-readline' Making check in ice-9 gmake[3]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/guile-readline/ice-9' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/guile-readline/ice-9' gmake[3]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/guile-readline' gmake[3]: Nothing to be done for `check-am'. gmake[3]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/guile-readline' gmake[2]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/guile-readline' gmake[1]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/guile-readline' Making check in emacs gmake[1]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/emacs' gmake[1]: Nothing to be done for `check'. gmake[1]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/emacs' Making check in srfi gmake[1]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/srfi' gmake check-am gmake[2]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/srfi' gmake[2]: Nothing to be done for `check-am'. gmake[2]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/srfi' gmake[1]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/srfi' Making check in doc gmake[1]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/doc' Making check in ref gmake[2]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/doc/ref' gmake check-am gmake[3]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/doc/ref' gmake[3]: Nothing to be done for `check-am'. gmake[3]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/doc/ref' gmake[2]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/doc/ref' Making check in tutorial gmake[2]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/doc/tutorial' gmake[2]: Nothing to be done for `check'. gmake[2]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/doc/tutorial' Making check in goops gmake[2]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/doc/goops' gmake[2]: Nothing to be done for `check'. gmake[2]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/doc/goops' Making check in r5rs gmake[2]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/doc/r5rs' gmake[2]: Nothing to be done for `check'. gmake[2]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/doc/r5rs' gmake[2]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/doc' gmake[2]: Nothing to be done for `check-am'. gmake[2]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/doc' gmake[1]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/doc' Making check in examples gmake[1]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/examples' gmake[1]: Nothing to be done for `check'. gmake[1]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/examples' Making check in test-suite gmake[1]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/test-suite' Making check in standalone gmake[2]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/test-suite/standalone' gmake check-am gmake[3]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/test-suite/standalone' gmake test-num2integral test-round test-list test-unwind test-conversion test-scm-c-read test-scm-take-locale-symbol test-with-guile-module test-scm-with-guile test-system-cmds test-bad-identifiers test-require-extension test-asmobs test-fast-slot-ref test-use-srfi test-extensions gmake[4]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/test
Re: i guess we're frozen & stuff
guile master fails to build on NetBSD because it passes characters to tolower, which is specified to take an int. It's really a macro, and this is a messy situation. The language weenies I've talked to about this think that in this case it's the program that passes a char that's wrong. Hence the following patch. Note that because tolower is specified to take an int, this promotion to int is what would happen if it really were a function, so this "can't be wrong" :-) See http://www.opengroup.org/onlinepubs/95399/functions/tolower.html and the statement about the argument being of type int and being of a restricted set of values. diff --git a/libguile/strings.c b/libguile/strings.c index c3ea8b8..437cedc 100644 --- a/libguile/strings.c +++ b/libguile/strings.c @@ -1427,8 +1427,8 @@ unistring_escapes_to_guile_escapes (char **bufp, size_t *lenp) /* Convert \u00NN to \xNN */ after[j] = '\\'; after[j + 1] = 'x'; - after[j + 2] = tolower (before[i + 4]); - after[j + 3] = tolower (before[i + 5]); + after[j + 2] = tolower ((int) before[i + 4]); + after[j + 3] = tolower ((int) before[i + 5]); i += 6; j += 4; } @@ -1440,12 +1440,12 @@ unistring_escapes_to_guile_escapes (char **bufp, size_t *lenp) /* Convert \U00NN to \UNN */ after[j] = '\\'; after[j + 1] = 'U'; - after[j + 2] = tolower (before[i + 4]); - after[j + 3] = tolower (before[i + 5]); - after[j + 4] = tolower (before[i + 6]); - after[j + 5] = tolower (before[i + 7]); - after[j + 6] = tolower (before[i + 8]); - after[j + 7] = tolower (before[i + 9]); + after[j + 2] = tolower ((int) before[i + 4]); + after[j + 3] = tolower ((int) before[i + 5]); + after[j + 4] = tolower ((int) before[i + 6]); + after[j + 5] = tolower ((int) before[i + 7]); + after[j + 6] = tolower ((int) before[i + 8]); + after[j + 7] = tolower ((int) before[i + 9]); i += 10; j += 8; } pgp2evFYxyymE.pgp Description: PGP signature
unsigned char confusion
In srfi-13.c line 25222, SCM_MAKE_CHAR is called with an argument that is an unsigned char. This leads to: cc1: warnings being treated as errors srfi-13.c: In function 'string_titlecase_x': srfi-13.c:2522: warning: comparison is always false due to limited range of data type srfi-13.c:2522: warning: comparison is always false due to limited range of data type This is because SCM_MAKE_CHAR (in libguile/chars.h) has a bizarre conditional that checks the argument for < 0, and if so casts it to unsigned char. Otherwise it does not cast. There is no comment that explains what the point is. Fairly obviously this is an attempt to avoid sign extension during SCM_MAKE_ITAG8. The value is then cast to uintptr_t which is also unsigned, but sign extension would set more bits. So, I think the cast to unsigned char should just always be there, without the test. pgpMzSj5PYRny.pgp Description: PGP signature
Re: i guess we're frozen & stuff
On Aug 11, 2009, at 07:34, Greg Troxel wrote: Have there been recent reports of success of 1.9.x on platforms other than GNU/Linux? Guile has been quite portable in the past and it's surely still very close if not there, and it would be a shame if 2.0 had issues. I realize this is hard for people to test if they don't have the platform, but it would be really good to have testing on at least one normal BSD and also Darwin. The Mac build off of "master" fails for me currently in srfi-13.c, with the comparison-always-false warning Greg discussed. I hacked around that, but then guile-readline doesn't build: Making all in guile-readline ../libguile/guile-snarf -o readline.x ../../guile-readline/readline.c - DHAVE_CONFIG_H -I. -I.. -I../../guile-readline/.. -I../../guile- readline/lib -I./lib -g -O2 In file included from ../../guile-readline/readline.c:29: ../../guile-readline/../libguile.h:25:17: error: gmp.h: No such file or directory In file included from ../../guile-readline/../libguile.h:95, from ../../guile-readline/readline.c:29: ../../guile-readline/../libguile/strings.h:26:21: error: uniconv.h: No such file or directory Neither the path specified for libgmp nor the path specified for libunistring at configure time is included here. I don't think any of this is Mac-specific; I'm surprised that it works on GNU/Linux systems. Perhaps I'm building it in ways that are unusual for the other developers (build dir != src dir, libgmp and guile-1.8 installed in the same place, libgmp and libunistring installed in different nonstandard directories)? If I use CPPFLAGS=... and LDFLAGS=... instead of --with-libfoo-prefix configure options to specify paths to find libgmp and libunistring, the tests still pick old, installed Guile headers (which this time I've poisoned to highlight the problem) from those locations instead of the in-tree versions: Making all in test-suite Making all in standalone ../../libguile/guile-snarf -o test-asmobs-lib.x ../../../test-suite/ standalone/test-asmobs-lib.c -DHAVE_CONFIG_H -I. -I../../../test-suite/ standalone -I../.. -I/opt/local/include -I/Users/raeburn/dev/guile/ libunistring-0.9.1/I/include -g -O2 -I../../.. -I../../../lib -I../../ lib -I../.. In file included from /opt/local/include/libguile.h:30, from ../../../test-suite/standalone/test-asmobs- lib.c:23: /opt/local/include/libguile/__scm.h:3:2: error: #error Poison! I might be building Guile as part of a larger package (*cough*Emacs*cough*) that wants to include stuff from the same system directories (e.g., for MacPorts, pkgsrc, whatever) where an old version of Guile is installed, and thus Guile gets passed CPPFLAGS/ LDFLAGS settings that add that old version to the search paths. So I think the CPPFLAGS/LDFLAGS version needs to be made to work, as well as the --with-libfoo-prefix version. With the attached patch, I can get guile to build with CPPFLAGS= and LDFLAGS= ... someone more familiar than I am with automake will have to fix the guile-readline stuff. Even with my patch, it fails its tests: make check-TESTS Testing /Users/raeburn/dev/guile/git/guile/b3/meta/guile ... with GUILE_LOAD_PATH=/Users/raeburn/dev/guile/git/guile/test-suite ERROR: In procedure make_objcode_by_mmap: ERROR: bad header on object file: "GOOF-0.6-LE-4---" FAIL: check-guile Still looking into that Ken guile-master.diff Description: Binary data
Re: i guess we're frozen & stuff
On Aug 11, 2009, at 09:59, Ken Raeburn wrote: ERROR: In procedure make_objcode_by_mmap: ERROR: bad header on object file: "GOOF-0.6-LE-4---" Ah, that was an old compiled file cached away in $HOME/.cache/ guile/... that I needed to delete in order to make the tests pass. I re-ran the test suite for the 1.9.1 release, and it creates a file with "GOOF-0.6" under ~/.cache/guile/ccache/1.9/... whereas the current master code creates (and requires?) a file with "GOOF-0.9" under the same prefix (and both appending the full pathname). So if I had built and tested guile-1.9.1 and then I update to 1.9.2 in the same directory (e.g., stripping off the version number so it can be found as "guile" in my project tree), it will fail its tests, if I don't know to get rid of this hidden cache file, and its pathname is not actually mentioned in the error message. That's kind of bad. It appears that the word size and endianness is also encoded into the header. Is this a good idea, when people can share home directories across machines of different architectures, and even run mixed-size binaries on a single system (or mixed-architecture, in some cases)? Ken
Re: unsigned char confusion
On Tue, 2009-08-11 at 09:39 -0400, Greg Troxel wrote: > In srfi-13.c line 25222, SCM_MAKE_CHAR is called with an argument that > is an unsigned char. This leads to: > > cc1: warnings being treated as errors > srfi-13.c: In function 'string_titlecase_x': > srfi-13.c:2522: warning: comparison is always false due to limited range of > data type > srfi-13.c:2522: warning: comparison is always false due to limited range of > data type > > This is because SCM_MAKE_CHAR (in libguile/chars.h) has a bizarre > conditional that checks the argument for < 0, and if so casts it to > unsigned char. Otherwise it does not cast. There is no comment that > explains what the point is. Fairly obviously this is an attempt to > avoid sign extension during SCM_MAKE_ITAG8. The value is then cast to > uintptr_t which is also unsigned, but sign extension would set more > bits. > > So, I think the cast to unsigned char should just always be there, without > the test. > Yeah, that was me. In the move to Unicode, I'm trying to get to a point where the underlying storage of characters is uint32. I was trying to come up with a macro that would cast all of char, unsigned char, and uint32 to uint32, since SCM_MAKE_CHAR is used in each of those cases in the code. If SCM_MAKE_CHAR receives something negative, it is from a signed char. For portability, it might be best if SCM_MAKE_CHAR becomes an inline function that takes int32, since the top bit of uint32 isn't used in encoding Unicode codepoints anyway. That would cover all those cases. Or, to save the macro, it could become #define SCM_MAKE_CHAR(x) \ (((scm_t_int32) (x) < 0)\ ? SCM_MAKE_ITAG8 ((scm_t_bits) (unsigned char) (x), scm_tc8_char) \ : SCM_MAKE_ITAG8 ((scm_t_bits) (x), scm_tc8_char)) Yeah, and better comments for that as well. -Mike
Re: i guess we're frozen & stuff
Ken Raeburn writes:
> ../../guile-readline/../libguile/strings.h:26:21: error: uniconv.h: No
> such file or directory
>
> Neither the path specified for libgmp nor the path specified for
> libunistring at configure time is included here.
Ag, that's what I feared with the inclusion of libunistring headers
in Guile's public headers.
Mike: can you fix it one way or another? Solutions are:
1. Fix `guile.pc' to have "-I${libunistring}", and fix guile-readline
CPPFLAGS as well.
2. Or just don't include in public headers. This means
you have to declare, say, `scm_t_string_failed_conversion_handler'
as a replacement for `iconv_ilseq_handler'.
I would prefer #2 for reasons explained in another message.
Thanks in advance!
Ludo'.
Re: i guess we're frozen & stuff
Hi, Ken Raeburn writes: > It appears that the word size and endianness is also encoded into the > header. Is this a good idea, when people can share home directories > across machines of different architectures, and even run mixed-size > binaries on a single system (or mixed-architecture, in some cases)? Currently `.go' files cannot be shared across heterogeneous architectures, which is why the endianness and word size are encoded in `.go' headers. Thanks, Ludo'.
Re: i guess we're frozen & stuff
On Aug 11, 2009, at 11:36, Ludovic Courtès wrote: It appears that the word size and endianness is also encoded into the header. Is this a good idea, when people can share home directories across machines of different architectures, and even run mixed-size binaries on a single system (or mixed-architecture, in some cases)? Currently `.go' files cannot be shared across heterogeneous architectures, which is why the endianness and word size are encoded in `.go' headers. That's fine... but shouldn't we maybe use different directories, then, so runs on different platforms don't collide? Ken
Re: i guess we're frozen & stuff
Greg Troxel writes:
> FAIL: bytevectors.test: 2.9 Operations on Strings: string->utf8 [latin-1]
> FAIL: bytevectors.test: 2.9 Operations on Strings: utf8->string [latin-1]
Does libunistring's "make check" pass on this platform?
> FAIL: i18n.test: locale objects: make-locale with unknown locale
Can you try this (run "./meta/guile"):
(use-modules (ice-9 i18n))
(make-locale LC_ALL "does-not-exist")
... and report the result?
> FAIL: i18n.test: nl-langinfo et al.: locale-day (1 arg)
What does "(map locale-day (map 1+ (iota 7)))" return?
> FAIL: i18n.test: nl-langinfo et al.: locale-day (2 args)
What does this return?
(map (lambda (day)
(locale-day day (make-locale LC_ALL "C")))
(map 1+ (iota 7)))
> FAIL: i18n.test: nl-langinfo et al.: locale-day (2 args, using
> `%global-locale')
and:
(map (lambda (day)
(locale-day day %global-locale))
(map 1+ (iota 7)))
> FAIL: bytevectors.test: 2.9 Operations on Strings: string->utf8 [latin-1]
> FAIL: bytevectors.test: 2.9 Operations on Strings: utf8->string [latin-1]
Again, might be a libunistring issue.
And why were some test files evaluated twice?!
> ERROR: srfi-19.test: SRFI date/time library: string->date understands days
> and months - arguments: ((misc-error string->date "TIME-ERROR type ~A: ~S"
> (bad-date-template-string ("Invalid string for " # priv:locale-long-weekday->index (string)>)) #f))
What does this do:
(use-modules (srfi srfi-19))
(let ((d (string->date "Saturday, December 9, 2006"
"~A, ~B ~d, ~Y")))
(date->time-utc (make-date (date-nanosecond d)
(date-second d)
(date-minute d)
(date-hour d)
(date-day d)
(date-month d)
(date-year d)
0)))
> ERROR: srfi-19.test: SRFI date/time library: string->date works on Sunday -
> arguments: ((misc-error string->date "TIME-ERROR type ~A: ~S"
> (bad-date-template-string ("Invalid string for " # priv:locale-abbr-weekday->index (string)>)) #f))
And this:
(use-modules (srfi srfi-19))
(let* ((str "Sun, 05 Jun 2005 18:33:00 +0200")
(date (string->date str "~a, ~d ~b ~Y ~H:~M:~S ~z")))
(date->string date))
I also noticed another problem (x86_64-unknown-linux-gnu):
--8<---cut here---start->8---
scheme@(guile-user)> (string=? "\u0100\u0101\x0102" "\u0100\u0101\x0102")
Backtrace:
In unknown file:
?: 0* [# #:4:0 ()>]
5: 1* [#:4:0 ()>]
?: 2* [string=? "\u0100\u0101\x0102" "\u0100\u0101\x0102"]
ERROR: In procedure string=?:
ERROR: Invalid read access of chars of wide string: "\u0100\u0101\x0102"
--8<---cut here---end--->8---
It's not a regression strictly speaking, but still. Mike? :-)
Thanks,
Ludo'.
Re: i guess we're frozen & stuff
On Tue, 2009-08-11 at 08:29 -0400, Greg Troxel wrote: > I built libunistring and tried to build master. Some tests failed, and > also the build failed due to warnings (post to follow). I think all the > failed tests are locale related. > A possible cause of some of this may be when I replaced toupper() with uc_toupper, leading to a confusion between locale-dependent case handling and Unicode codepoint case handling. Probably should revert the uc_toupper and uc_tolower calls for now until the conversion is more complete. Odd that I didn't see these errors, though. -Mike
Re: i guess we're frozen & stuff
On Tue, 2009-08-11 at 17:54 +0200, Ludovic Courtès wrote: > I also noticed another problem (x86_64-unknown-linux-gnu): > > --8<---cut here---start->8--- > scheme@(guile-user)> (string=? "\u0100\u0101\x0102" "\u0100\u0101\x0102") > > Backtrace: > In unknown file: >?: 0* [# #:4:0 ()>] >5: 1* [#:4:0 ()>] >?: 2* [string=? "\u0100\u0101\x0102" "\u0100\u0101\x0102"] > > ERROR: In procedure string=?: > ERROR: Invalid read access of chars of wide string: "\u0100\u0101\x0102" > --8<---cut here---end--->8--- > > It's not a regression strictly speaking, but still. Mike? :-) All of srfi-13.c isn't ready to operate on non-8-bit strings. string=? calls MY_VALIDATE_SUBSTRING_SPEC_COPY, which calls scm_i_string_chars. scm_i_string_chars either returns a pointer to the Latin-1 strings or errors with the error you saw. -Mike
Re: i guess we're frozen & stuff
Mike Gran writes:
> All of srfi-13.c isn't ready to operate on non-8-bit strings. string=?
> calls MY_VALIDATE_SUBSTRING_SPEC_COPY, which calls scm_i_string_chars.
> scm_i_string_chars either returns a pointer to the Latin-1 strings or
> errors with the error you saw.
OK, thanks for the explanation.
Apparently the disassembler needs to be taught Unicode:
--8<---cut here---start->8---
scheme@(guile-user)> ,c x
Disassembly of #:
0(load-symbol "\x01");; .
6(add)
7(link-now)
8(variable-ref)
9(return)
scheme@(guile-user)> ,c y
Disassembly of #:
0(load-symbol "\x01");; .
6(sub)
7(link-now)
8(variable-ref)
9(return)
scheme@(guile-user)> ,c a
Disassembly of #:
Backtrace:
In system/base/compile.scm:
244: 0 [decompile-fold # # #f ...]
In language/assembly/decompile-bytecode.scm:
37: 1 [decompile-bytecode # #f ()]
In language/assembly/decompile-bytecode.scm:
88: 2 [lp ((load-symbol "\x01"))]
In language/assembly/decompile-bytecode.scm:
100: 3 [# {97}]
In unknown file:
?: 4* [opcode->instruction {97}]
ERROR: In procedure opcode->instruction:
ERROR: Wrong type argument in position 1 (expecting INSTRUCTION_P): 97
scheme@(guile-user)> ,c d
Disassembly of #:
0(load-symbol "\x01");; .
6(not)
7(link-now)
8(variable-ref)
9(return)
scheme@(guile-user)> ,c c
Disassembly of #:
Backtrace:
In system/base/compile.scm:
244: 0 [decompile-fold # # #f ...]
In language/assembly/decompile-bytecode.scm:
37: 1 [decompile-bytecode # #f ()]
In language/assembly/decompile-bytecode.scm:
88: 2 [lp ((load-symbol "\x01"))]
In language/assembly/decompile-bytecode.scm:
100: 3 [# {99}]
In unknown file:
?: 4* [opcode->instruction {99}]
ERROR: In procedure opcode->instruction:
ERROR: Wrong type argument in position 1 (expecting INSTRUCTION_P): 99
scheme@(guile-user)> ,c abcd
Disassembly of #:
0(load-symbol "\x01abc") ;; .abc
9(not)
10(link-now)
11(variable-ref)
12(return)
--8<---cut here---end--->8---
Ideas on how to fix this?
Thanks,
Ludo'.
Re: i guess we're frozen & stuff
Does libunistring's "make check" pass on this platform?
should have tried that. testlocale.c fails on line 38 with:
test-locale.c:38: error: expected ')' before numeric constant
expanding that with cpp gets me the rather stunning:
extern int (* verify_function__ (void)) [(!!sizeof (struct { unsigned int
verify_error_if_negative_size__: (sizeof (void *)0 == sizeof (void *)) ? 1 :
-1; }))];
which I'll rewrap to:
extern int (* verify_function__ (void))
[(!!sizeof (struct {
unsigned int verify_error_if_negative_size__ : (sizeof (void *)0 ==
sizeof (void *)) ? 1 : -1; }
))];
which seems odd but not necessarily wrong. The original line was
verify (sizeof NULL == sizeof (void *));
So it seems that NULL is expanding to (void *) 0, and "sizeof (void *)
0" is not legit. AFAIK sizeof is specified to work on variables and
types, and NULL is neither a variable nor a type.
Is NULL something else on Linux?
Fixing that so sizeof(NULL) gets this to pass with only one failure:
test-striconveh.c:389: assertion failed
Abort (core dumped)
FAIL: test-striconveh
pgptHmH3LzmGQ.pgp
Description: PGP signature
Re: i guess we're frozen & stuff
Just checking: I assume we don't care about binary compatibility between 1.9.x unstable releases? Hence changing function signatures and structure contents, and deleting symbols, while not changing the library's major version number, is okay? Ken
Re: i guess we're frozen & stuff
requested tests follow
list gdt 52 ~/BUILD-GUILE-master/guile > ./meta/guile
;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-autocompile argument to disable.
;;; compiling
/home/gdt/BUILD-GUILE-master/guile/guile-readline/ice-9/readline.scm
;;; compiled
/home/gdt/.cache/guile/ccache/1.9/home/gdt/BUILD-GUILE-master/guile/guile-readline/ice-9/readline.scm.go
Guile Scheme interpreter 0.5 on Guile 1.9.1
Copyright (C) 2001-2008 Free Software Foundation, Inc.
Enter `,help' for help.
scheme@(guile-user)> (use-modules (ice-9 i18n))
scheme@(guile-user)> (make-locale LC_ALL "does-not-exist")
#
scheme@(guile-user)> (map locale-day (map 1+ (iota 7)))
("Sun" "Mon" "Tue" "Wed" "Thu" "Fri" "Sat")
scheme@(guile-user)> (map (lambda (day)
(locale-day day (make-locale LC_ALL "C")))
(map 1+ (iota 7)))
("Sun" "Mon" "Tue" "Wed" "Thu" "Fri" "Sat")
scheme@(guile-user)> (map (lambda (day)
(locale-day day %global-locale))
(map 1+ (iota 7)))
("Sun" "Mon" "Tue" "Wed" "Thu" "Fri" "Sat")
scheme@(guile-user)> (use-modules (srfi srfi-19))
(let ((d (string->date "Saturday, December 9, 2006"
scheme@(guile-user)> "~A, ~B ~d,
~Y")))
(date->time-utc (make-date (date-nanosecond d)
(date-second d)
(date-minute d)
(date-hour d)
(date-day d)
(date-month d)
(date-year d)
0)))
Backtrace:
In unknown file:
?: 0* [# #]
In standard input:
35: 1* [#]
In srfi/srfi-19.scm:
1462: 2 [string->date "Saturday, December 9, 2006" "~A, ~B ~d, ~Y"]
In srfi/srfi-19.scm:
1438: 3 [priv:string->date # 0 "~A, ~B ~d, ~Y" ...]
In srfi/srfi-19.scm:
176: 4 [priv:time-error string->date bad-date-template-string ...]
In unknown file:
?: 5* [throw misc-error misc-error ...]
ERROR: In procedure string->date:
ERROR: TIME-ERROR type bad-date-template-string: ("Invalid string for "
#index (string)>)
scheme@(guile-user)> (use-modules (srfi srfi-19))
(let* ((str "Sun, 05 Jun 2005 18:33:00 +0200")
(date (string->date str "~a, ~d ~b ~Y ~H:~M:~S ~z")))
(date->string date))
scheme@(guile-user)>
Backtrace:
In unknown file:
?: 0* [# #]
In standard input:
47: 1* [#]
In srfi/srfi-19.scm:
1462: 2 [string->date "Sun, 05 Jun 2005 18:33:00 +0200" "~a, ~d ~b ~Y ~H:~M:~S
~z"]
In srfi/srfi-19.scm:
1438: 3 [priv:string->date # 0 "~a, ~d ~b ~Y ~H:~M:~S ~z" ...]
In srfi/srfi-19.scm:
176: 4 [priv:time-error string->date bad-date-template-string ...]
In unknown file:
?: 5* [throw misc-error misc-error ...]
ERROR: In procedure string->date:
ERROR: TIME-ERROR type bad-date-template-string: ("Invalid string for "
#index (string)>)
pgpe83GldARSq.pgp
Description: PGP signature
Re: i guess we're frozen & stuff
Hi, For me the build of the current master fails with: libtool: compile: gcc -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 -I.. -I.. -I../lib -I../lib -pthread -Wall -Wmissing-prototypes -Werror -fvisibility=hidden -O3 -g -march=athlon-xp -MT libguile_la-strings.lo -MD -MP -MF .deps/libguile_la-strings.Tpo -c strings.c -fPIC -DPIC -o .libs/libguile_la-strings.o cc1: warnings being treated as errors strings.c: In function ‘scm_string_append’: strings.c:1300: error: ‘data’ may be used uninitialized in this function make[3]: *** [libguile_la-strings.lo] Error 1 It is easy to disable -Werror or set the offending variable to NULL, but with my limited knowledge of Guile internals it seems that this uninitialized pointer is indeed passed to scm_i_make_string or scm_i_make_wide_string which do not seem to reserve space for it and even dereference the pointer. Might be just me, but it seems there is something weird going on here.. -- Juhani
Re: i guess we're frozen & stuff
> From: Ludovic Courtès l...@gnu.org > Apparently the disassembler needs to be taught Unicode: There's a disassembler? In the assembler, the string, symbol, keyword, and define are changed from -- 3 bytes: string length LENGTH bytes: one byte chars -- to -- 3 bytes: string length 1 bytes: bytes per char LENGTH*BYTES_PER_CHAR bytes: character array -- where the character array is either and 8-bit chars array or a 32-bit native endian unsigned integer array. so, the reverse op needs to make it into the disassembler for string, keyword, symbol, and define. But, I've never checked out the disassembler before. I'll look at it tonight. Thanks, -Mike
Re: i guess we're frozen & stuff
> From: Juhani Viheräkoski moonsh...@kapsi.fi > Hi, > > For me the build of the current master fails with: > > libtool: compile: gcc -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 -I.. -I.. -I../lib > -I../lib -pthread -Wall -Wmissing-prototypes -Werror -fvisibility=hidden -O3 -g > -march=athlon-xp -MT libguile_la-strings.lo -MD -MP -MF > .deps/libguile_la-strings.Tpo -c strings.c -fPIC -DPIC -o > .libs/libguile_la-strings.o > cc1: warnings being treated as errors > strings.c: In function ‘scm_string_append’: > strings.c:1300: error: ‘data’ may be used uninitialized in this function > make[3]: *** [libguile_la-strings.lo] Error 1 > > It is easy to disable -Werror or set the offending variable to NULL, but with my > limited knowledge of Guile internals it seems that this uninitialized pointer is > indeed passed to scm_i_make_string or scm_i_make_wide_string which do not > seem > to reserve space for it and even dereference the pointer. Might be just me, but > it seems there is something weird going on here.. > This one's okay, I think. The allocation is made in make_stringbuf and `data' is set to point to its buffer. We'll have to set it to NULL in scm_string_append and other places to quiet warnings. > -- Juhani Thanks, -Mike
Re: i guess we're frozen & stuff
On Aug 11, 2009, at 13:04, Greg Troxel wrote: So it seems that NULL is expanding to (void *) 0, and "sizeof (void *) 0" is not legit. AFAIK sizeof is specified to work on variables and types, and NULL is neither a variable nor a type. No, sizeof should work fine on expression values as well. I'm not quite sure about the question of syntax here -- sizeof's operand may be "an expression or the parenthesized name of a type". (So "sizeof var" is just a special case of the expression version, and doesn't require parentheses.) But if the expression starts with a parenthesized type because it's a cast... looking at the grammar, I'd think it would be valid, but that would have implications for code such as "sizeof (unsigned long) + 3" ... is that a single expression (3UL) you're taking the size of, or a sum involving the size of a type? Certainly "sizeof ((void *)0)", with the extra parens, works, and I think I've nearly always seen pointer versions of "NULL" using the enclosing parentheses, perhaps because of just this issue. Assuming "sizeof (TYPE) EXPR" isn't valid, I'd call it a defect in your system's definition of NULL, though I wouldn't go so far as to call it non-compliant. One could also argue that an expression provided to sizeof should always be parenthesized unless you know the syntax of it won't be altered by sticking "sizeof" in front, e.g., "sizeof(3+4)" instead of "sizeof 3+4". However, they're testing for a POSIX 2008 requirement that C99 and POSIX 2004 implementations need not meet, namely that NULL be of type "void *" instead of any null pointer constant (e.g., "0"). I think requiring POSIX 2008 support for Guile and anything that builds on it seems like a bad idea. I haven't looked at the libunistring code to see why it might be relevant, but it seems like a pretty gratuitous imposition to me. The only benefit of it I can see is that a variadic function can then take NULL as an argument without casting to char*; is that worth refusing to support other systems? Is NULL something else on Linux? I'm not sure if it's GNU libc or GCC, but I'm getting "((void *)0)". Ken
Re: i guess we're frozen & stuff
Greg Troxel writes: > Does libunistring's "make check" pass on this platform? > > should have tried that. testlocale.c fails on line 38 with: Can you report it upstream? > So it seems that NULL is expanding to (void *) 0, and "sizeof (void *) > 0" is not legit. AFAIK sizeof is specified to work on variables and > types, and NULL is neither a variable nor a type. > > Is NULL something else on Linux? On GNU it's "#define NULL ((void *)0)". Can you try this: echo '#include ' | cpp -dM - | grep NULL (assuming cpp(1) is from GCC.) Thanks, Ludo'.
Re: i guess we're frozen & stuff
The essential bit is: #define NULL (void *)0 pgpuZFJtB2uAZ.pgp Description: PGP signature
i18n issues on NetBSD
Greg Troxel writes:
> scheme@(guile-user)> (make-locale LC_ALL "does-not-exist")
> #
And `(setlocale LC_ALL "does-not-exist")'?
It looks like setlocale(3) doesn't behave as specified by POSIX
(http://www.opengroup.org/onlinepubs/9699919799/functions/setlocale.html).
> scheme@(guile-user)> (map locale-day (map 1+ (iota 7)))
> ("Sun" "Mon" "Tue" "Wed" "Thu" "Fri" "Sat")
It looks like `(nl-langinfo DAY_1)' doesn't DTRT per
http://www.opengroup.org/onlinepubs/9699919799/basedefs/langinfo.h.html .
Just to make sure, can you try this program (assume the `en_GB' locale
is available):
--8<---cut here---start->8---
#include
#include
#include
#include
#include
int
main (int argc, char *argv[])
{
char *s;
s = setlocale (LC_ALL, "C");
assert (s != NULL);
printf ("DAY_1: %s\n", nl_langinfo (DAY_1));
s = setlocale (LC_ALL, "en_GB");
assert (s != NULL);
printf ("DAY_1: %s\n", nl_langinfo (DAY_1));
return 0;
}
--8<---cut here---end--->8---
> ERROR: In procedure string->date:
> ERROR: TIME-ERROR type bad-date-template-string: ("Invalid string for "
> #index (string)>)
This is actually the same problem.
Thanks,
Ludo'.
Re: i guess we're frozen & stuff
Greg Troxel writes: > #define NULL (void *)0 This is under-parenthesized! Two actions to be taken: 1. Report a bug to your favorite libc maintainers. ;-) 2. Ask libunistring folks at http://savannah.gnu.org/projects/libunistring/ to replace "sizeof NULL" by "sizeof (NULL)" in `test-locale.c'. Thanks, Ludo'.
Re: i guess we're frozen & stuff
Ken Raeburn writes: > Just checking: I assume we don't care about binary compatibility > between 1.9.x unstable releases? Hence changing function signatures > and structure contents, and deleting symbols, while not changing the > library's major version number, is okay? Yes. Ludo'.
Re: i guess we're frozen & stuff
Mike Gran writes:
>> From: Juhani Viheräkoski moonsh...@kapsi.fi
[...]
>> strings.c: In function ‘scm_string_append’:
>> strings.c:1300: error: ‘data’ may be used uninitialized in this function
>> make[3]: *** [libguile_la-strings.lo] Error 1
[...]
> This one's okay, I think. The allocation is made in make_stringbuf and
> `data'
> is set to point to its buffer.
>
> We'll have to set it to NULL in scm_string_append and other places to quiet
> warnings.
Yes. Or use "union { char *narrow; scm_t_wchar *wide; }" to make things
obvious.
Thanks,
Ludo'.
Re: i guess we're frozen & stuff
Ken Raeburn writes: > However, they're testing for a POSIX 2008 requirement that C99 and > POSIX 2004 implementations need not meet, namely that NULL be of type > "void *" instead of any null pointer constant (e.g., "0"). I think > requiring POSIX 2008 support for Guile and anything that builds on it > seems like a bad idea. I haven't looked at the libunistring code to > see why it might be relevant, but it seems like a pretty gratuitous > imposition to me. The only benefit of it I can see is that a variadic > function can then take NULL as an argument without casting to char*; > is that worth refusing to support other systems? I didn't know it was a POSIX 2008 requirement. Then indeed, we should discuss this with the libunistring folks. Thanks, Ludo'.
Re: i guess we're frozen & stuff
l...@gnu.org (Ludovic Courtès) writes: > Ken Raeburn writes: > >> However, they're testing for a POSIX 2008 requirement that C99 and >> POSIX 2004 implementations need not meet, namely that NULL be of type >> "void *" instead of any null pointer constant (e.g., "0"). I think >> requiring POSIX 2008 support for Guile and anything that builds on it >> seems like a bad idea. I haven't looked at the libunistring code to >> see why it might be relevant, but it seems like a pretty gratuitous >> imposition to me. The only benefit of it I can see is that a variadic >> function can then take NULL as an argument without casting to char*; >> is that worth refusing to support other systems? > > I didn't know it was a POSIX 2008 requirement. Then indeed, we should > discuss this with the libunistring folks. gnulib upstream claims that while they are testing for POSIX 2008, it's only to behave right if it isn't met. But the test code fails when NULL is '(void *)0'. As I read a reply on a netbsd list, C99 says that NULL is a constant with value 0 or that vast to void *, and "(void *)0" seems to meet that requirement quite nicely. I wonder if it's a gcc bug that 'sizeof (void *) 0' fails. Regardless, guile aims to be far more portable than POSIX 2008 (which I had not even heard of until today, and at work I'm one of the chief ranters making people read posix instead of assuming the way their linux box behaves is the spec). pgpnc4BC68etH.pgp Description: PGP signature
Re: i18n issues on NetBSD
scheme@(guile-user)> (setlocale LC_ALL "does-not-exist")
"C"
list gdt 8 ~ > cat l.c
#include
#include
#include
#include
#include
int
main (int argc, char *argv[])
{
char *s;
s = setlocale (LC_ALL, "C");
assert (s != NULL);
printf ("DAY_1: %s\n", nl_langinfo (DAY_1));
s = setlocale (LC_ALL, "en_GB");
assert (s != NULL);
printf ("DAY_1: %s\n", nl_langinfo (DAY_1));
return 0;
}
list gdt 9 ~ > cc -o l l.c
list gdt 10 ~ > ./l
DAY_1: Sun
DAY_1: Sun
But if I run this on a linux box I get
gdt 78 ~ > ./l
DAY_1: Sunday
l: l.c:20: main: Assertion `s != ((void *)0)' failed.
Aborted
I'm afraid I don't really understand i18n details.
pgpepXvZF8rMJ.pgp
Description: PGP signature
Re: i guess we're frozen & stuff
l...@gnu.org (Ludovic Courtès) writes: > Greg Troxel writes: > >> #define NULL (void *)0 > > This is under-parenthesized! > > Two actions to be taken: > > 1. Report a bug to your favorite libc maintainers. ;-) I think that's a legal value for NULL per C99. Interestingly it has not apparently caused other trouble. We'll see what others say, and I can see the point that having it parenthesized is defensive even if it's legal as is. > 2. Ask libunistring folks at > http://savannah.gnu.org/projects/libunistring/ to replace > "sizeof NULL" by "sizeof (NULL)" in `test-locale.c'. I did, and this has been committed to their repo for gnulib. pgpUcbmmYjIvS.pgp Description: PGP signature
Re: i guess we're frozen & stuff
Greg Troxel writes:
> I wonder if it's a gcc bug that 'sizeof (void *) 0' fails.
My understanding of Section A.2.1 of C99 is that both this and
"sizeof ((void *) 0)" are syntactically invalid:
(6.5.1) primary-expression:
identifier
constant
string-literal
( expression )
(6.5.2) postfix-expression:
primary-expression
postfix-expression [ expression ]
postfix-expression ( argument-expression-listopt )
postfix-expression . identifier
postfix-expression -> identifier
postfix-expression ++
postfix-expression --
( type-name ) { initializer-list }
( type-name ) { initializer-list , }
[...]
(6.5.3) unary-expression:
postfix-expression
++ unary-expression
-- unary-expression
unary-operator cast-expression
sizeof unary-expression
sizeof ( type-name )
(6.5.3) unary-operator: one of
& * + - ~!
(6.5.4) cast-expression:
unary-expression
( type-name ) cast-expression
Do you have pointers to the discussions you've had with the Gnulib and
NetBSD people?
Thanks,
Ludo'.
Re: i18n issues on NetBSD
Greg Troxel writes:
> scheme@(guile-user)> (setlocale LC_ALL "does-not-exist")
> "C"
This looks wrong to me:
Upon successful completion, setlocale() shall return the string
associated with the specified category for the new locale. Otherwise,
setlocale() shall return a null pointer and the locale of the process
is not changed.
http://www.opengroup.org/onlinepubs/9699919799/functions/setlocale.html
Here we do not expect "successful completion", so it "shall return a
null pointer".
Can you submit a bug report against NetBSD's C library?
> list gdt 8 ~ > cat l.c
> #include
> #include
> #include
>
> #include
> #include
>
>
> int
> main (int argc, char *argv[])
> {
> char *s;
>
> s = setlocale (LC_ALL, "C");
> assert (s != NULL);
>
> printf ("DAY_1: %s\n", nl_langinfo (DAY_1));
>
> s = setlocale (LC_ALL, "en_GB");
> assert (s != NULL);
>
> printf ("DAY_1: %s\n", nl_langinfo (DAY_1));
>
> return 0;
> }
> list gdt 9 ~ > cc -o l l.c
> list gdt 10 ~ > ./l
> DAY_1: Sun
> DAY_1: Sun
Both look wrong to me: it returns the abbreviated name of the day
instead of the full name of the day
(http://www.opengroup.org/onlinepubs/9699919799/basedefs/langinfo.h.html).
Can you report a bug for this one, too?
Thanks,
Ludo'.
