Safe subset of C?

[Robert Vazan]

I am looking for other people's attempts to create safe subset of C and
enforce it with scripts. Does anybody know about anything like this?

By "safe", I mean the following:
* Strongly typed memory. No way to reinterpret it as bunch of bytes
* Recovery from invalid and NULL pointers other than crash
* Possibility to isolate piece of code by not giving it key pointers

Library used to support such safe subset must not introduce its own flaws.
For example, it is not a good idea to use int proxies for pointers like
Unix API does, because this allows pointer guessing and consequently
prevents isolation.

[Morris Dovey]

Robert Vazan wrote:

I am looking for other people's attempts to create safe subset of C and
enforce it with scripts. Does anybody know about anything like this?

By "safe", I mean the following:
* Strongly typed memory. No way to reinterpret it as bunch of bytes
* Recovery from invalid and NULL pointers other than crash
* Possibility to isolate piece of code by not giving it key pointers

Library used to support such safe subset must not introduce its own flaws.
For example, it is not a good idea to use int proxies for pointers like
Unix API does, because this allows pointer guessing and consequently
prevents isolation.

Robert...

Search in Google groups (comp.lang.c). There have already been a
number of threads discussing this topic.

--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

[Mark Haigh]

Robert Vazan wrote:

I am looking for other people's attempts to create safe subset of C and
enforce it with scripts. Does anybody know about anything like this?

By "safe", I mean the following:
* Strongly typed memory. No way to reinterpret it as bunch of bytes
* Recovery from invalid and NULL pointers other than crash
* Possibility to isolate piece of code by not giving it key pointers

Library used to support such safe subset must not introduce its own flaws.
For example, it is not a good idea to use int proxies for pointers like
Unix API does, because this allows pointer guessing and consequently
prevents isolation.

Look at MISRA C guidelines, at www.misra.org.uk, which is enforcable
with commercial lint-like tools. You must order a hardcopy. I did and
found it to be an interesting read.

However, if you're really interested in high-integrity coding, perhaps
something like SPARK (Ada subset) may interest you as well.

If you insist on something C-based, MISRA-C with something like VxWorks
for Safety Critical Systems (www.windriver.com) may be a candidate,
depending on what you're looking for.
Mark F. Haigh
mf*****@sbcglob al.net

[Kelsey Bjarnason]

On Fri, 21 Nov 2003 13:47:49 +0100, Robert Vazan wrote:

I am looking for other people's attempts to create safe subset of C and
enforce it with scripts. Does anybody know about anything like this?

By "safe", I mean the following:
* Strongly typed memory. No way to reinterpret it as bunch of bytes

It occurs to me that this requirement alone pretty much removes your
quest from anything remotely related to C.

[Simon Biber]

"Kelsey Bjarnason" <ke*****@lights peed.bc.ca> wrote:

On Fri, 21 Nov 2003 13:47:49 +0100, Robert Vazan wrote:

By "safe", I mean the following:
* Strongly typed memory. No way to reinterpret it as bunch of
bytes

It occurs to me that this requirement alone pretty much removes
your quest from anything remotely related to C.

It depends how you define "remotely related to C". You would essentially
have to disallow pointer arithmetic and therefore change the way that
arrays work. It starts to look quite like Java, and indeed Java has many
features for limited 'sandbox' operation inbuilt, for running unauthorised
code on client machines. I'd say Java is still related to C.

--
Simon.

[James Hu]

On 2003-11-22, Kelsey Bjarnason <ke*****@lights peed.bc.ca> wrote:

On Fri, 21 Nov 2003 13:47:49 +0100, Robert Vazan wrote:

I am looking for other people's attempts to create safe subset of C and
enforce it with scripts. Does anybody know about anything like this?

By "safe", I mean the following:
* Strongly typed memory. No way to reinterpret it as bunch of bytes

It occurs to me that this requirement alone pretty much removes your
quest from anything remotely related to C.

It is a "safe subset". You could define a subset that:

* does not allow the use of unions;
* does not allow declarations of void pointers;
* does not allow defining functions that return void pointers; and
* does not allow casts.

You could write a lint like tool to help enforce the subset. Also, any
diagnostic emitted by the compiler would have to be addressed.

-- James

[Robert Vazan]

On Sat, 22 Nov 2003 00:08:59 -0600, James Hu wrote:

* does not allow the use of unions;
* does not allow declarations of void pointers;
* does not allow defining functions that return void pointers; and
* does not allow casts.

Add arrays, ellipsis arguments, and memory deallocation and I can start
considering it safe. Some replacement must be provided for arrays and
memory management. Your rules also prohibit interfaces.

[James Hu]

On 2003-11-22, Robert Vazan <ro*********@pr ivateweb.sk> wrote:

On Sat, 22 Nov 2003 00:08:59 -0600, James Hu wrote:

* does not allow the use of unions;
* does not allow declarations of void pointers;
* does not allow defining functions that return void pointers; and
* does not allow casts.
Add arrays,

Why? I was questioning myself about disallowing unions. Since acquiring
the value of a member union other than the last one stored into invokes
unspecified behavior, a "good enough" lint should be able to flag this.

Similarly for arrays, bounds checking should be enforced.

I guess the safe subset should explicitly state:

* does not allow unspecified or undefined behaviors.
ellipsis arguments,
Yes, I suppose definining your own varable argument functions should be
disallowed. Using printf and friends should be allowed, though.
and memory deallocation and I can start
considering it safe.
Hmm? If you disallow memory deallocation, you have to disallow memory
allocation as well.

If unspecified and undefined behaviors are not allowed, memory
deallocation should be safe.

I guess one could require an interface for each type to be allocated and
deallocated:

int * malloc_int_arra y(int number_of_ints) ;
void free_int_array( int *int_array);

And have the free wrapper do whatever it needed to do to make sure it
was freeing something its corresponding wrapper allocated. But a good
memory error debugging tool can already help enforce that.
Some replacement must be provided for arrays and
memory management.
I think I took care of that.
Your rules also prohibit interfaces.

How so?

-- James

[Gordon Burditt]

>It is a "safe subset". You could define a subset that:

* does not allow the use of unions;
* does not allow declarations of void pointers;
* does not allow defining functions that return void pointers; and
* does not allow casts.

You could write a lint like tool to help enforce the subset. Also, any
diagnostic emitted by the compiler would have to be addressed.

A really "safe" subset of C needs to disallow:

- Pointers or pointer-valued expressions, including (library or
otherwise) functions that accept or return them.
- Variables.
- Side effects, particularly including assignment, op= operators,
I/O, and memory allocation/deallocation.
- Casts.

I think it is possible to have the compiler compile this to "safe"
assembly language with one of three opcodes: halt EXIT_SUCCESS,
halt EXIT_FAILURE, or branch-to-self.

Gordon L. Burditt

[Robert Vazan]

On Sun, 23 Nov 2003 01:21:18 +0000, Gordon Burditt wrote:

A really "safe" subset of C needs to disallow:
Here I assume that you claim that this is best (least restrictive) safe
subset that can be made.
- Pointers or pointer-valued expressions, including (library or
otherwise) functions that accept or return them.
Too restrictive. You cannot show that it is necessary.
- Variables.
Why?
- Side effects, particularly including assignment, op= operators,
Why?
I/O,
Standard I/O maybe, but why all I/O?
and memory allocation/deallocation.
Unnecessarily restrictive, once again.
I think it is possible to have the compiler compile this to "safe"
assembly language with one of three opcodes: halt EXIT_SUCCESS,
halt EXIT_FAILURE, or branch-to-self.

Sure, but I am uncertain whether your subset is really the only option.