diff options
author | Joseph Myers <joseph@codesourcery.com> | 2021-10-20 13:38:50 +0000 |
---|---|---|
committer | Joseph Myers <joseph@codesourcery.com> | 2021-10-20 13:38:50 +0000 |
commit | 2c6cabb3a442f467e78c702cffbd5f003f87f44f (patch) | |
tree | 9e42250a8069bbfb4c2bafe91bfe3593e0b6d0e1 /rt/tst-cputimer2.c | |
parent | ad6f2a010c2ce759936de4747f6e0d53991912f8 (diff) | |
download | glibc-2c6cabb3a442f467e78c702cffbd5f003f87f44f.tar glibc-2c6cabb3a442f467e78c702cffbd5f003f87f44f.tar.gz glibc-2c6cabb3a442f467e78c702cffbd5f003f87f44f.tar.bz2 glibc-2c6cabb3a442f467e78c702cffbd5f003f87f44f.zip |
Correct access attribute on memfrob (bug 28475)
As noted in bug 28475, the access attribute on memfrob in <string.h>
is incorrect: the function both reads and writes the memory pointed to
by its argument, so it needs to use __read_write__, not
__write_only__. This incorrect attribute results in a build failure
for accessing uninitialized memory for s390x-linux-gnu-O3 with
build-many-glibcs.py using GCC mainline.
Correct the attribute. Fixing this shows up that some calls to
memfrob in elf/ tests are reading uninitialized memory; I'm not
entirely sure of the purpose of those calls, but guess they are about
ensuring that the stack space is indeed allocated at that point in the
function, and so it matters that they are calling a function whose
semantics are unknown to the compiler. Thus, change the first memfrob
call in those tests to use explicit_bzero instead, as suggested by
Florian in
<https://sourceware.org/pipermail/libc-alpha/2021-October/132119.html>,
to avoid the use of uninitialized memory.
Tested for x86_64, and with build-many-glibcs.py (GCC mainline) for
s390x-linux-gnu-O3.
Diffstat (limited to 'rt/tst-cputimer2.c')
0 files changed, 0 insertions, 0 deletions