Re: C's trikery semantic opens up backdoor in new Linux kernel

[Dave Thompson <david.thompson1@worldnet.att.net>]

On Wed, 12 Nov 2003 14:38:06 +0100, Duncan Sands <baldrick@free.fr>
wrote:

> > >IMHO the real problem is that
<snip>
> > >uid is not an opaque type and can
> > >be changed with a simple assignment.  Much better if that required
> > >a function call.
> >
> > You can almost always find a workaround. The problem is to use it
> > everytime and force people to use it.
> 
> I was under the impression that (using preprocessor trickery) it was possible
> to get the equivalent of an Ada private type in C.  Then everyone is forced
> to use function calls to get/set the value, unless they do type casts etc.
> In all cases, abuse would stand out more than it does now.
> 
There's nothing you can do with the C preprocessor that can't be done
directly in source -- because the preprocessor is a source-to-source
transform (actually source to lexed-source, but that's equivalent in
capability). The only compiler-enforced opaque types in C are
incomplete aka "forward" struct and union tags. And, probably sadly,
there are enough places in most large C programs where casts are
legitimately used that a few more don't stand out that much.

You can make it harder to find/see things, like typedefs, by burying
them in #include files, perhaps several layers deep in confusing
#if's, but they're there somewhere and someone who goes to the effort
can find and use them. You can use BIG_UGLY_NAMES that attract
scrutiny if actually written in source -- like Ada's UNCHECKED_* but
more so because you can't substitute lowercase.

For assignment, you can with a little extra work create and expose
only a const pointer to data that is actually variable; this then can
be assigned to only in code that has the "variable view" OR by casting
the pointer to non-const, which is at least mildly inconvenient.

- David.Thompson1 at worldnet.att.net