This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C undefined behavior fix
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: dewar at gnat dot com
- Cc: Dautrevaux at microprocess dot com, paulus at samba dot org, Franz dot Sirl-kernel at lauterbach dot com, benh at kernel dot crashing dot org, gcc at gcc dot gnu dot org, jtv at xs4all dot nl, linux-kernel at vger dot kernel dot org, linuxppc-dev at lists dot linuxppc dot org, minyard at acm dot org, rth at redhat dot com, trini at kernel dot crashing dot org, velco at fadata dot bg
- Date: Fri, 04 Jan 2002 09:38:35 +0100
- Subject: Re: [PATCH] C undefined behavior fix
- References: <20020103132837.71EFBF3257@nile.gnat.com>
dewar@gnat.com writes:
> <<No, in fact the kernel isn't written in ANSI C. :)
> If nothing else, the fact that it uses a lot of gcc-specific
> extensions rules that out. And it assumes that you can freely cast
> pointers to unsigned longs and back again. I'm sure others can add to
> this list.
>>>
>
> Most certainly this list should exist in precise defined form.
C99 includes a list of additional guarantees made by many C
implementations (in an informative index). I think we really should
check this list (and the list of implementation-defined behavior) and
document the choices made by GCC. In fact, this documentation is
required by the standard.
> It is this kind of informality that is asking for trouble.
We have seen much trouble in this area before, but I doubt we can
avoid all of them by proper documentation. Quite a few people seem to
write some C code, check that it works, look at the generated machine
code, and if it seems to be correct, the C code is considered to be
correct.