This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Possible problem with inline string functions in glibc, sysdeps/i386/i486/bits/string.h
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Davin McCall <davmac at ozonline dot com dot au>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Thu, 2 Jan 2003 14:16:22 +0100
- Subject: Re: Possible problem with inline string functions in glibc, sysdeps/i386/i486/bits/string.h
- References: <20030103001501.7f57ffd1.davmac@ozonline.com.au>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Jan 03, 2003 at 12:15:01AM +1100, Davin McCall wrote:
> Hi,
>
> I'm a bit worried that the dummy ouput operands for a couple
> of the implemented-as-asm functions in sysdeps/i386/i486/bits/string.h
> aren't really correct.
>
> Specifically the "mem*()" class of functions take "void *" arguments and
> therefore I assume that in fact any type of pointer (say an "int *" or
> some sort of struct ptr) could be passed to these functions.
> However, a character array is used as the dummy output operand for these
> functions.
>
> Due to aliasing considerations it seems to me that it might then
> be possible for the compiler to assume that (in the case where the type
> of the argument is not actually char *) the buffer contents have not
> changed across the function call. Therefore it might cache values
> from the buffer in registers and use those same values after the
> function call when the buffer is accessed, even though the
> buffer has really been modified.
See ISO C99, 6.5 (7):
An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:
-- a type compatible with the effective type of the object,
...
-- a character type.
Jakub