Re: Big-endian Gcc on Intel IA32

[Linus Torvalds <torvalds at transmeta dot com>]

On 18 Dec 2001, Morten Welinder wrote:
> Now I realize that you are not about to rewrite the kernel in C++
> (unless you have sampled a bit too much Glogg recently, :-)  What
> I am saying is that you could probably make minor changes to the
> current source code such that...
>
> 1. Its C interpretation does not change.
> 2. Its C++ interpretation would have a user_data* type and do the
>    check you ask for.

Well, there is actually a project (the "stanford checker") which goes even
further than this, and does an instrumented gcc back-end, where you can
add a lot of almost arbitrary rules on what constitutes tainting.

The problem with it is that it's not automatic, and it doesn't give the
kind of "immediate feedback" as a direct compiler warning or error does.

Your suggestion of using C++ as a separate checker is not really much more
than a very cut-down version of the (quite interesting) standford project.
It might make it slightly easier for people to check, but it's not quite
there..

> I seem to remember that once upon a time you said that you wanted
> type int when you deal with ints (as opposed to having some typedef
> name like off_t).  If that is still true, I guess you will not like
> this kind of approach.

I don't like abstraction for abstractions sake - a lot of people seem to
want to abstract things just because they _can_, not because it makes any
real sense. For example, POSIX wanted to abstract the "length of a socket
name", and created "socklen_t", which simply _has_ to be the same as "int"
if you are going to be compatible with historical uses (and has to support
all the same operations etc, so it's not a opaque type in any case). That
is a useless abstraction - you're not actually adding information, you're
only adding chaos.

However, in other cases it can be quite useful to specify a "immutable"
type. There are many cases where you have basically integer types, but
they are integers that have emplicit meaning, and doing arithmetic on them
is a nonsensical operation.

Linux actually ends up embedding some of these as unique structures, just
because that's the only way to strengthen the C type set. It does
sometimes impact code quality (gcc seems to be better at returning
integers than returning integers wrapped in a structure etc), but not by
much, and the abstraction you get in these cases is definitely worth it.

However, creating a new structure type for each thing is actually quite a
lot of effort, and gets tedious. So just a set of "taint bits" would be
syntactically easier.

(To the person suggesting how to do it in C++ - you _can_ get a subset of
this in C by the above "embed in a structure" trick).

		Linus