This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C undefined behavior fix
- From: Joe Buck <jbuck at synopsys dot COM>
- To: paulus at samba dot org
- Cc: jbuck at synopsys dot COM (Joe Buck), dewar at gnat dot com, velco at fadata dot bg,gcc at gcc dot gnu dot org, linux-kernel at vger dot kernel dot org,linuxppc-dev at lists dot linuxppc dot org, trini at kernel dot crashing dot org
- Date: Thu, 3 Jan 2002 07:45:24 -0800 (PST)
- Subject: Re: [PATCH] C undefined behavior fix
> > There is already such a project under development: see
> >
> > http://gcc.gnu.org/projects/bp/main.html
> >
> > This is a modification to gcc that implements pointers as triples.
> > While there is a performance penalty for doing this, it can completely
> > eliminate the problem of exploitable buffer overflows. However, programs
> > that violate the rules of ISO C by generating out-of-range pointers will
> > fail.
>
> What will it do if I cast a pointer to unsigned long? Or if I cast an
> unsigned long to a pointer? The kernel does both of these things, and
> in a lot of places.
Perhaps you need to reread a book like K&R, second edition, to find out
what the C language promises you and what it doesn't.
The bounded-pointer approach represents a C pointer as three machine
pointers. When you cast to unsigned long, it converts the "value"
pointer. When you cast an unsigned long to a pointer, you lose the range
information, so the pointer's extent is anywhere in memory. However,
if the compiler can determine by dataflow analysis where this value
came from it is entitled to put the original range information back.
> Part of my beef with what gcc-3 is doing is that I take a pointer,
> cast it to unsigned long, do something to it, cast it back to a
> pointer, and gcc _still_ thinks it's knows what I am doing. It
> doesn't.
The C language standard defines quite precisely what the compiler is
allowed to assume and what it is not allowed to assume. If you don't
like these rules, you will dislike *all* modern C compilers, especially
the expensive proprietary C compilers hardware vendors often use to
get good SPEC results.