** Also affects: valgrind via
https://bugs.kde.org/show_bug.cgi?id=307828
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1089722
Title:
wcslen reads
According to https://bugs.kde.org/show_bug.cgi?id=307828, should be
fixed in valgrind 3.9
** Bug watch added: KDE Bug Tracking System #307828
https://bugs.kde.org/show_bug.cgi?id=307828
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I can confirm this bug. I already posted a question on stackoverflow a
few weeks ago (stackoverflow.com/questions/14474691/wifstream-with-
imbue-locale-produces-valgrind-errors) before I did deeper
investigation. In my current project I work with wstring/wchar_t and
also locale / imbue and
It sounds like it's not going to cross a page boundary then, so it safe,
in which case, it's a false positive and valgrind should be configured
to ignore it.
** Package changed: eglibc (Ubuntu) = valgrind (Ubuntu)
** Changed in: valgrind (Ubuntu)
Importance: Undecided = Medium
** Changed
Hmm my x86 is a bit rusty; have you got an actual test case that
triggers the warning?
It seems to be basically:
a) Do a bunch of individual character tests (32 bit at a time)
b) Do a bunch of tests of 64 bit words (pcmpeqd's) - i.e. 2 wchar's at a time
c) Get into an aligned loop doing 64
Have you got any examples?
IMHO this can just be a false positive since it's safe to read beyond a buffer
end iff:
* You know you're not crossing a 64bit boundary (since you know you're not
crossing a page boundary and hence can't seg)
* Don't cause any data in that 64bit read to influence
I suspected it may be a false positive in valgrind from such an
optimization in eglibc, but looking at the uncommented glibc source, I
can not tell if it actually is safe and won't cross a page boundary. If
it can't cross a page boundary, then yes, valgrind should be configured
to ignore it, but
