This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/17499] wcslen() returns wrong result on x86_64
- From: "digitalfreak at lingonborough dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 22 Oct 2014 23:00:11 +0000
- Subject: [Bug libc/17499] wcslen() returns wrong result on x86_64
- Auto-submitted: auto-generated
- References: <bug-17499-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17499
--- Comment #2 from Rafal Luzynski <digitalfreak at lingonborough dot com> ---
More info:
- 32-bit architecture is also affected if uses SSE2;
- wcschr() and wcsrchr() have the same problem.
(In reply to joseph@codesourcery.com from comment #1)
> On Tue, 21 Oct 2014, digitalfreak at lingonborough dot com wrote:
>
> > - the string is placed at the memory address which is not a multiple of 4.
>
> Why do you think this is a valid use of wcslen?
Both compilers and the architecture allow this operation. At the moment the
only reason why it should be invalid is the way that wcslen() and similar
functions have been implemented.
> The x86_64 ABI says that
> int (= wchar_t) has 4-byte alignment.
Yes, so unaligned data should be discouraged for performance reasons but not
invalid. And if it was invalid it should raise an error rather than just
return incorrect result.
> (Indeed, there's a special m68k
> version of wcpcpy to deal with m68k having lower alignment requirements
> than generic code expects.)
This is the solution I would like to have for x86, too.
--
You are receiving this mail because:
You are on the CC list for the bug.