Why? If memcpy can then be expanded in line, and the string is short, this
can be a *huge* win...
> As a subnote, what you sent was sent
> to Linus with a comment about working around a gcc-3.0
> bug/feature, and
> was rejected because of this.
> 2) We could modify the RELOC macro, and not have this problem. The
> patch was posted, but not acted upon.
I think we MUST modify the RELOC macro. Currently the code has an undefined
meaning WRT th eC standard, so is allowed to do almost anything from working
as expected (quite bad in fact: it may suddenly fail when sth is modified
elsewhere), to triggering the 3rd World War :-)
> 3) We could also try turning off this particular optimization
> (-fno-builtin perhaps) on this file, and not worry about it.
That's a compiler dependant way to fix the problem that creates a constraint
on the compiler: it MUST then from now continue to have a given behaviour to
some undefined feature (that is in fact not even documented...)
Note that the RELOC macro triggers an UNDEFINED behaviour, not an
IMPLEMENTATION DEFINED one, so the compiler writer is free of any constraint
and that would be a genuine extension the the C language to fix the
behaviour.
Bernard
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: dautrevaux@microprocess.com
b.dautrevaux@usa.net
--------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/