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]

Re: wcscpy broken


Andreas Schwab wrote:
>James Antill <nevyn-glibc-alpha@and.org> writes:
>|>  ISO 9899:1999 says...
>|> 
>|>      The wcscpy function copies the wide string pointed to by s2
>|>      (including the terminating null wide character) into the array
>|>      pointed to by s1.
>|> 
>|> ...if it's not aligned properly, then it's not a valid wide
>|> string.
>
>... correct alignment is implementation dependent, and
>__alignof__(wchar_t) is not necessarily equal to sizeof(wchar_t).

Actually, __alignof__ is a GCC extension that does not necessarily
return the 'required alignment' as used by the C standard, but rather
the alignment usually *recommended* for best performance ...

>If __alignof__(wchar_t) == 1 then the compiler can put the constant at any
>address (modulo performance considerations).

... which is why I'd argue the compiler can put the constant at any
address even if __alignof__ (wchar_t) > 1, at least on platforms without
alignment requirements, like i386 or s390.

In fact, in my error scenario, gcc 2.95.3 on s390 *does* return 
__alignof__ (wchar_t) == 4, even though it does not adhere to its
own recommended value in the case of wide string constants.

I certainly agree that this should be fixed in the compiler (and it
*is* fixed in gcc 3.x);  I'm just wondering whether glibc shouldn't
accept non-aligned wide strings anyway as long as they can be validly
generated.  (E.g. by placing a wide string inside a 'packed' struct,
or at a non-aligned offset inside a malloc'ed block ...)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de


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