Optimization of strcpy with an offset outside the string

Optimization of strcpy with an offset outside the string

[Corey Minyard]

In the PowerPC Linux kernel, at some points in time the reference to 
some constant data is at an offset (because the MMU is not set up yet). 
 So you see expressions like:

   print("test" + offset);

where offset is far outside the bounds of the string.  This causes some 
very strange behaviour.  Basically, gcc emits code to subtract the 
offset varaible from the length of the string  to calculate the length 
to memcpy.  In builtins.c in the function c_strlen(), I find the comment:

      /* We don't know the starting offset, but we do know that the string
         has no internal zero bytes.  We can assume that the offset falls
         within the bounds of the string; otherwise, the programmer deserves
         what he gets.  Subtract the offset from the length of the string,
         and return that.  This would perhaps not be valid if we were 
dealing
         with named arrays in addition to literal string constants.  */

Should the programmer really lose in this case?  I can work around it in 
the kernel, but I thought I would point this out.

-Corey

BTW, My cable modem is now operational again, so you can mail me at acm.org.

Re: Optimization of strcpy with an offset outside the string

[Daniel Jacobowitz]

On Mon, Dec 03, 2001 at 08:45:26PM -0600, Corey Minyard wrote:
> In the PowerPC Linux kernel, at some points in time the reference to 
> some constant data is at an offset (because the MMU is not set up yet). 
> So you see expressions like:
> 
>   print("test" + offset);
> 
> where offset is far outside the bounds of the string.  This causes some 
> very strange behaviour.  Basically, gcc emits code to subtract the 
> offset varaible from the length of the string  to calculate the length 
> to memcpy.  In builtins.c in the function c_strlen(), I find the comment:
> 
>      /* We don't know the starting offset, but we do know that the string
>         has no internal zero bytes.  We can assume that the offset falls
>         within the bounds of the string; otherwise, the programmer deserves
>         what he gets.  Subtract the offset from the length of the string,
>         and return that.  This would perhaps not be valid if we were 
> dealing
>         with named arrays in addition to literal string constants.  */
> 
> Should the programmer really lose in this case?  I can work around it in 
> the kernel, but I thought I would point this out.
> 
> -Corey
> 
> BTW, My cable modem is now operational again, so you can mail me at acm.org.

Is this still in the current PPC kernels?

Franz raised this issue several months ago, and I believe the verdict
was that it was illegal.

I personally wouldn't mind a warning being generated, though!

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer