This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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);

returns 0,

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.

  union locale_data_value
  {
    const uint32_t *wstr;
    const char *string;
    unsigned int word;
  }
  values [];

Which is not going to work for any big endian 64-bit platform (like
PowerP64)..

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
issue.








Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]