Re: [PATCH] C undefined behavior fix

Aaron Lehmann (aaronl@vitelus.com)
Wed, 2 Jan 2002 03:28:21 -0800


--BOKacYhQ+x31HxR3
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 02, 2002 at 01:03:25AM +0200, Momchil Velikov wrote:
> Thus=20
> strcpy (dst, "abcdef" + 2)
> gives
> memcpy (dst, "abcdef" + 2, 5)

IMHO gcc should not be touching these function calls, as they are not
made to a standard C library, and thus have different behaviors. I'm
suprised that gcc tries to optimize calls to these functions just
based on their names.

The gcc manpage mentions

-ffreestanding
Assert that compilation takes place in a freestanding
environment. This implies -fno-builtin. A freestand=AD
ing environment is one in which the standard library
may not exist, and program startup may not necessarily
be at "main". The most obvious example is an OS ker=AD
nel. This is equivalent to -fno-hosted.

Why is Linux not using this? It sounds very appropriate. The only
things the manpage mentions that -fno-builtin would inhibit from being
optimized are memcpy() and alloca(). memcpy() has its own assembly
optimization and inlining on some (most?) archs, and as for alloca(),
I only see it being used a bit in the S/390 code, where the gcc
optimizations could quite possibly break something. I think
-ffreestanding definately should be used by the kernel to prevent gcc
from messing with its code in broken ways.

--BOKacYhQ+x31HxR3
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8Mu7VdtqQf66JWJkRAhUmAJ4nsHAVyUHIjpDvcG+6Efg4L54U5ACaA5HP
hPDf4de5XmyxtfLQW0EOtBw=
=Mkjc
-----END PGP SIGNATURE-----

--BOKacYhQ+x31HxR3--
-
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/