Re: [9fans] plan or side effect

["Thomas Bushnell, BSG" <tb+usenet@becket.net>]

dhog@plan9.bell-labs.com (David Gordon Hogan) writes:

> It certainly knows about strcpy() and memmove() (or
> whatever they're #defined to in the headers).  So for
> instance,
> 
> 	strcpy(s, "xyzzy");
> 
> will get replaced with a bunch of instructions to store the
> appropriate constant values in s.

Actually, that's glibc that's doing the trick, not gcc.

As I said, since GCC and glibc are maintained separately, gcc is very
careful to stay away from magic related to things like "strcpy".
(There is an exception for "main"; some magic happens there, and GCC
and glibc worked out carefully how it should happen.)

If you look at <bits/string2.h> you can see the glibc magic for
strcpy.  It boils down to the following:

  define strcpy(dest, src) \
  (__extension__ (__builtin_constant_p (src)				      \
		  ? (__string2_1bptr_p (src) && strlen (src) + 1 <= 8	      \
		     ? __strcpy_small (dest, __strcpy_args (src),	      \
				       strlen (src) + 1)		      \
		     : (char *) memcpy (dest, src, strlen (src) + 1))	      \
		  : strcpy (dest, src)))

The only compiler support for this is the __builtin_constant_p
function, which is a GCC builtin.  (There is a GCC __builtin_memcpy,
as well, which does get used for larger strings inside the guts of
memcpy, and expands to an inline block memory copy instruction.)

The function __strcpy_small (which is invoked in the case where src is
the constant "xyzzy") is an inline function that moves the bytes one
word at a time, and then the compiler simply optimizes those
assignments in the usual way to produce:

foo:
	pushl %ebp
	movl %esp,%ebp
	movl s,%eax
	movl $2054846840,(%eax)
	movw $121,4(%eax)
	leave
	ret