Correct access attribute on memfrob (bug 28475)
Checks
| Context |
Check |
Description |
| dj/TryBot-apply_patch |
success
|
Patch applied to master at the time it was sent
|
| dj/TryBot-32bit |
success
|
Build for i686
|
Commit Message
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, add a memset call before
the memfrob call in those tests to avoid the use of uninitialized
memory.
Tested for x86_64, and with build-many-glibcs.py (GCC mainline) for
s390x-linux-gnu-O3.
Comments
* Joseph Myers:
> 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.
That part looks okay.
> 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, add a memset call before the memfrob call in those
> tests to avoid the use of uninitialized memory.
Using explicit_bzero would be more idomatic, I think.
Florian
@@ -26,6 +26,7 @@ static void
deeper (void (*f) (void))
{
char stack[1100 * 1024];
+ memset (stack, 123, sizeof stack);
memfrob (stack, sizeof stack);
(*f) ();
memfrob (stack, sizeof stack);
@@ -25,6 +25,7 @@ static void
deeper (void (*f) (void))
{
char stack[1100 * 1024];
+ memset (stack, 123, sizeof stack);
memfrob (stack, sizeof stack);
(*f) ();
memfrob (stack, sizeof stack);
@@ -227,6 +227,7 @@ static void
deeper (void (*f) (void))
{
char stack[1100 * 1024];
+ memset (stack, 123, sizeof stack);
memfrob (stack, sizeof stack);
(*f) ();
memfrob (stack, sizeof stack);
@@ -495,7 +495,7 @@ extern char *strfry (char *__string) __THROW __nonnull ((1));
/* Frobnicate N bytes of S. */
extern void *memfrob (void *__s, size_t __n) __THROW __nonnull ((1))
- __attr_access ((__write_only__, 1, 2));
+ __attr_access ((__read_write__, 1, 2));
# ifndef basename
/* Return the file name within directory of FILENAME. We don't