This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: wcscpy broken
- From: Ulrich Weigand <weigand at immd1 dot informatik dot uni-erlangen dot de>
- To: schwab at suse dot de
- Cc: nevyn-glibc-alpha at and dot org, uweigand at de dot ibm dot com, libc-alpha at sources dot redhat dot com
- Date: Sun, 2 Feb 2003 23:33:28 +0100 (MET)
- Subject: 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