This is the mail archive of the glibc-bugs@sourceware.org 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 libc/17499] wcslen() returns wrong result on x86_64


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.


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