This is the mail archive of the
mailing list for the glibc project.
bug-regex5 fails for PowerPC64
- From: "Steve Munroe" <sjmunroe at us dot ibm dot com>
- To: Roland McGrath <roland at redhat dot com>, aj at suse dot de, geoffk at geoffk dot org
- Cc: libc-alpha at sources dot redhat dot com
- Date: Tue, 10 Sep 2002 13:53:20 -0500
- Subject: bug-regex5 fails for PowerPC64
The posix test bug-regex5 fails with "No collating element!" when compiled
for the PowerPC64 (CVS Head from 09/06 with the rest of my PPC64 patches).
The problem is that the statement:
table_size = (size_t) nl_langinfo (_NL_COLLATE_SYMB_HASH_SIZEMB);
The function nl_langinfo is excuting the statement:
return (char *) data->values[index].string;
to extract the table_size from the field "word" in the following union
within the locate_data struct.
const uint32_t *wstr;
const char *string;
unsigned int word;
Which is not going to work for any big endian 64-bit platform (like
In this case the 32-bit "word" is aligned with the high-order 32-bits of
the 64-bit pointers (*string and *wstr). So nl_langinfo
(_NL_COLLATE_SYMB_HASH_SIZEMB); returns the 64-bit value with "word"
shifted left 32-bits. The assignment to table_size (a int32_t) truncates
this value to 32-bit, which leaving zero.
The function nl_langinfo seems to be new. In glibc-2.2.5 bug-regex5.c used
the _NL_CURRENT_WORD macro which accessed the value[index].word field
directly and loaded the correct value.
For testing I am changing the word field to unsigned long. I am not certain
that this is best solution across the platforms. Also it seems like a bad
idea the pass an integer value a char* under any circumstances. But that is
just my opinion. So I wait your input on the best way to resolve this