[Cryptography] I don't get it.

[Bear]

On Thu, 2014-04-17 at 13:10 +0100, Peter Fairbrother wrote:

> But, suppose you could go back in time, and adjust C and gcc, preferably 
> without assassinations. What would you change?
> 

Bounds checking should be part of array and string semantics.
ALL string semantics including strcopy, strcat, etc, should never
have had any bounds-unchecked versions in the first place.  

Zero-terminated strings were a Bad Idea.  Strings should have 
had explicit lengths from the beginning.

Bounds checking should be part of stack semantics.  Stack 
scribbling should get a guaranteed halt with a frame error as 
opposed to continuing until 'return' lands in a scribbled frame 
or, even worse, follows a scribbled pointer to 'return' to an 
entirely different location.

Bounds checking should be part of the semantics for all reads 
and writes to dynamically-allocated memory.  

'char' should never have been any kind of integer, and should never 
have been assignable nor comparable to integers without a cast. It 
could make sense for 'char' to have a value indistinguishable from 
a length-1 string, but never to have a value indistinguishable from
a length-1 integer.

NULL, unless cast to some particular type, should never have been 
a valid value for comparison or assignment.  Documentation for 
system calls that rely on NULL, in particular, should have to 
tell you exactly what type of NULL they rely on.  

Errors should have been a type.  Routines that return 'success 
or failure' should be returning (errortype)NULL for success or 
an error value (not just setting 'errno' but returning a value) 
for failure.  Errors should not be comparable to nor assignable to
any other type without a cast.

There should have been a proper boolean type from the beginning.
Booleans should never have been assignable nor comparable to 
another type without a cast.

> Malloc and free? Only in kernels and kexts, maybe drivers at a pinch.
> 

Eh.  I don't have a problem with them, although I'd want to see 
users provided with *other* methods of doing dynamic memory that 
make them less attractive;  in particular, there should be library 
calls for building and managing dynamically allocated data 
structures that tuck the malloc/free stuff under the corners where 
the user doesn't need to do it themselves.  

Sometimes the user needs sharp tools; but if you can anticipate 
the need, it's nicer to give him what he needs so he doesn't need 
to use the sharp tools to carve it for himself.

> Another thing I'd like to see as a (mandatory) goal would be repeatable 
> compilation, so if you used the same source, compiler and compiler 
> settings then you got the same object code out.

This is already true, isn't it, with the caveat that you also have
to rely on it being the same set of system libraries?


			Bear