This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch to add builtin strncmp and builtin strncpy
- To: Geoff Keating <geoffk at geoffk dot org>
- Subject: Re: Patch to add builtin strncmp and builtin strncpy
- From: Jakub Jelinek <jakub at redhat dot com>
- Date: Sun, 26 Nov 2000 16:28:35 -0500
- Cc: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>, gcc-patches at gcc dot gnu dot org
- References: <200011261918.OAA07147@caip.rutgers.edu> <jmvgtazb7j.fsf@geoffk.org>
- Reply-To: Jakub Jelinek <jakub at redhat dot com>
On Sun, Nov 26, 2000 at 01:15:44PM -0800, Geoff Keating wrote:
> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
>
> > This patch adds builtins for strncpy and strncmp as described on the
> > GCC projects page. The transformations done are:
> >
> > strncpy(s1, s2, 0) -> NOP
> > (handling side-effects of s1 & s2)
> >
> > strncpy(s1, "string", n) -> memcpy (s1, "string", n)
> > (where strlen("string")+1 >= n)
>
> Why not also
>
> strncpy(s1, "string", n) -> memcpy (s1, "string", sizeof ("string")+1)
> (where strlen("string")+1 < n)
Because they do different thing, strncpy has to pad it with '\0' up to
length n.
The transformation could be really
-> slen = strlen ("string") + 1;
memcpy (s1, "string", slen);
memset (s1 + slen, 0, n - slen);
but then the question is if it is really an optimization (it could be if
both memcpy and memset are inlined (especially if it would be inlined
mempcpy), but doing 2 function calls would be bad.
Alternatively, if difference between slen and n was very small, we could
create new string cst which would have additional 0 at the end (or even
better cooperate with varasm if the string constant has not been output yet,
pad it at the end for everyone).
Jakub