Re: 'Cyclone', a safer C--reinventing the wheel

[James Rogers <jimmaureenrogers@worldnet.att.net>]

Gautier Write-only-address wrote:
> will a "stronger C" be accepted by programmers if it has lost
> its "quick & dirty" features ? Where is the tradeoff between
> compatibility and security in that Cyclone ? That would be
> interesting information.

This, of course, is yet to be seen. 

After reading *some* of the Cyclone documentation I see that there is
a strong compatibility with classic C. Two incompatibilities are
implicit conversions and pointer arithmetic. Implicit conversions are
severely limited in Cyclone because of strong type checking.
Pointer arithmetic is allowed only when using "fat" pointers.
These "fat" pointers are used for array indices and maintain array
range information, making them "fatter" than normal pointers.

The normal C pointer notation still exists:

  int a = 10;
  int *b = &a;

This notation does not allow pointer arithmetic. Fat pointers are
created as follows:

  int a[10];
  int ?b = a;

This creates a fat pointer to the beginning of the "a" array.

Note that fat pointers make pointer arithmetic safer, but they do
not make array indexing safer.

Cyclone still uses the C #include technology, with all its power
and dangers. Cyclone does generate run-time checking to enhance
software safety. I believe this run-time checking will be its
undoing in the C community. Run-time checking will make 
Cyclone executables larger than executables created from a C
compiler using the same source code. 

It is my opinion that the C community still values small executable
size over software safety. If this was not true most people in the
C community would use a safer language.

Jim Rogers
Colorado Springs, Colorado USA