This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: wcscpy broken
James Antill <nevyn-glibc-alpha@and.org> writes:
|> "Ulrich Weigand" <Ulrich.Weigand@de.ibm.com> writes:
|>
|> > Note the pointer difference 'dest - src'; this invokes undefined
|> > behaviour according to the C standard because dest and src are
|> > not guaranteed to point into the same array.
|>
|> But is valid code for gcc, glibc uses a lot of idioms that aren' ISO
|> 9899 blessed.
This is true, but ...
|> > And in fact this generates incorrect code if one of dest and src
|> > is not sizeof(wchar_t)-aligned (which, while unusual and a bit
|> > inefficient, is valid as far as I can see).
|>
|> 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).
|> > I've had an actual bug report due to this because gcc 2.95.3 does
|> > not always align wide character string constants to 4 bytes, so a
|> > 'wcscpy (str, L"some constant")' can trigger the bug.
|>
|> That's a compiler bug. And you'll get failures for: wcslen(),
|> wcsnlen(), wprintf(), etc. and all code outside glibc which does
|> similar things.
If __alignof__(wchar_t) == 1 then the compiler can put the constant at any
address (modulo performance considerations).
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."