Re: Patch to add builtin strncmp and builtin strncpy

[Jakub Jelinek <jakub at redhat dot com>]

On Sun, Nov 26, 2000 at 03:28:03PM -0500, Kaveh R. Ghazi wrote:
>  > From: "Joseph S. Myers" <jsm28@cam.ac.uk>
>  > 
>  > On Sun, 26 Nov 2000, Kaveh R. Ghazi wrote:
>  > 
>  > > strncmp(s1, "string", n) -> strcmp(s1, "string")
>  > > strncmp("string", s2, n) -> strcmp("string", s2)
>  > >   (where strlen("string") < n)
>  > 
>  > As noted on the web page, the C standard requires arguments to strcmp, but
>  > not to strncmp, to be null-terminated.  If an implementation is found that
>  > reads beyond the expected point in the non-constant string in strcmp, this
>  > will need to be dealt with.
> 
> Sigh, I suppose it would be considered "legal" for the strcmp
> implementation to call strlen on each arg before doing any
> comparisons.  That would barf if s1 wasn't null terminated in the
> original call to strncmp.  Perhaps that particular transformation
> isn't valid, now I'm not sure.

Well, what should be IMHO certainly safe is to call expand_builtin_strcmp()
directly in expand_builtin_strncmp.
Then it is the question whether e.g. glibc (which knows this kind of
transformation is ok for it) should do it in its headers or whether gcc
should have some information about glibc implementation, I think the former
is probably better (but glibc definition will have to check for
strncmp(const, const, const) case and pass that into __builtin_strncmp).

	Jakub