Re: [PATCH] C undefined behavior fix

[Paul Mackerras <paulus@samba.org>]

Momchil Velikov writes:

> Well, you may discuss it again, but this time after actually reading
> the C standard:
> 
>     "6.3.6 Additive operators
>       ...  
>      
>      9 Unless both the pointer operand and the result point to
>        elements of the same array object, or the pointer operand
>        points one past the last element of an array object and the
>        result points to an element of the same array object, the
>        behavior is undefined if the result is used as an operand of a
>        unary * operator that is actually evaluated."

One of the reasons why C is a good language for the kernel is that its
memory model is a good match to the memory organization used by the
processors that linux runs on.  Thus, for these processors, adding an
offset to a pointer is in fact simply an arithmetic addition.  Combine
that with the fact that the kernel is far more aware of how stuff is
laid out in its virtual memory space than most C programs, and you can
see that it is reasonable for the kernel to do pointer arithmetic
which might be undefined according to the strict letter of the law,
but which in fact works correctly on the class of processors that
Linux runs on, for all reasonable compiler implementations.

The rules in the C standard are designed to allow a program to run
consistently on a wide variety of machine architectures, including
things like the DEC PDP-10 which weren't directly byte-addressable.
(Yes the PDP-10 had "byte pointers" but they were a different kind of
object from an ordinary pointer.)  The Linux kernel runs on a more
restricted range of machines and IMHO we are entitled to assume things
because of that.

> Why gcc shouldn't be making some optimization. Because a particular
> person doesn't like it or ?  What kind of statement is that anyway ?

This is the kernel.  If I say strcpy I want the compiler to call a
function called strcpy, not to try to second-guess me and do something
different.  If I want memcpy I'll write "memcpy".

> Although all uses of the RELOC macro violate the standard, this kind
> of pointer arithmetic is far too common and usually produces the
> expected behavior, thus it make sense to optimize the cases where ut
> breaks

If the gcc maintainers think they are entitled to change the memory
model so as to break pointer arithmetic that "violates" the standard,
then we will have to use a different compiler.

As for the original problem, my preferred solution at the moment is to
add an label in arch/ppc/lib/string.S so that string_copy() is the
same function as strcpy(), and use string_copy instead of strcpy in
prom.c.

Paul.