On Wed, May 21, 2008 at 12:53:34PM +0200, Roman Zippel wrote:
Hi,
On Wed, 21 May 2008, Al Viro wrote:
It actually was strlen that was generated and not strcat.
Here it replaced strncat() with call of strcat() (gcc 4.0.1, FWIW).
And yes, I can show you init/main.s with
jbsr strcat |
in it generated on kernel in b0rken range...
Please use a more recent compiler, 4.0 created too many problems on m68k,
which we only got under control with 4.1, so at least on m68k 4.0 is not
really supported.
Then it's worth mentioning in Documentation/Changes, IMO... Anyway,
updating m68k toolchain is not a problem; I'll get around to it tonight.
I still think that out-of-line implementation is a good idea, if nothing
else it would prevent future crap of the same kind if some later version
decides that strlen(a) + strlen(b) can be proven to be less than size
argument of strncat(), etc.
Technically we _are_ in nasal daemon country with redefining str*, unless
we pass -ffreestanding; m68k doesn't, so we can't guarantee that new stuff
of that kind won't crop up. IOW, it might be a good policy to have fallback
implementations of potentially affected primitives...
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
