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
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
stri
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
apparentl
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 =
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
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
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
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'.
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 `
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
The essential bit is:
#define NULL (void *)0
pgpuZFJtB2uAZ.pgp
Description: PGP signature
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
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.
> 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
> 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 leng
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-stri
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
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
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
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 explana
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 fil
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 t
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
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-ar
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 so
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 libunis
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 al
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 sui
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 p
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: war
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 th
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 `/h
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
33 matches
Mail list logo
