This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: c/10339: strncmp generates imPure code
- From: Michael Ubell <ubell at mindspring dot com>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 7 Apr 2003 20:56:01 -0000
- Subject: Re: c/10339: strncmp generates imPure code
- Reply-to: Michael Ubell <ubell at mindspring dot com>
The following reply was made to PR optimization/10339; it has been noted by GNATS.
From: Michael Ubell <ubell at mindspring dot com>
To: Andreas Schwab <schwab at suse dot de>
Cc: Falk Hueffner <falk dot hueffner at student dot uni-tuebingen dot de>, Wolfgang Bangerth
<bangerth at ices dot utexas dot edu>, gcc-bugs at gcc dot gnu dot org,
gcc-gnats at gcc dot gnu dot org
Subject: Re: c/10339: strncmp generates imPure code
Date: Mon, 07 Apr 2003 13:53:09 -0700
I think I see what is happening. I guess computers are smarter ;-)
Andreas Schwab wrote:
> Michael Ubell <ubell at mindspring dot com> writes:
>
> |> Do you mean you want me to set up a case where it runs off the
> |> end of memory?
>
> Yes.
Can't happen.
>
> |> I think it is sufficient that it is reading memory
> |> that is not allocated, no?
>
> No, it is not.
Well it would be but memcmp does not read the memory.
>
> It is. Memory returned by malloc is required to be correctly aligned for
> any type.
>
I'm still not clear what alignment has to do with it.
The optimization takes advantage of the fact that a properly formatted
string which is shorter than the constant string cannot compare passed its
end because there must be a null byte there.
Purify must have a different model of what memcmp does. I'll send
it to them.
Thanks
Mike