C的安全子集？ [英] Safe subset of C?

问题描述

我正在寻找其他人尝试创建C的安全子集和

使用脚本强制执行它。有没有人知道这样的事情？


通过安全，我的意思是：

*强类型内存。无法将其重新解释为一堆字节

*从崩溃以外的无效和NULL指针中恢复

*通过不给出关键指针来隔离代码片段的可能性


用于支持这种安全子集的库不得引入自己的缺陷。

例如，对于像
Unix API可以，因为它允许指针猜测，因此

可以防止隔离。

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 Vazan写道：

Robert Vazan wrote:

我正在寻找其他人尝试创建C的安全子集并使用脚本强制执行它。有没有人知道这样的事情？

通过安全，我的意思是：
*强类型的内存。无法将其重新解释为一堆字节
*从崩溃以外的无效和NULL指针中恢复
*可以通过不给它关键指针来隔离代码片段

使用的库支持这样的安全子集一定不能引入自己的缺陷。
例如，对于像Unix / Unix这样的指针使用int代理不是一个好主意，因为这允许指针猜测，因此
防止隔离。

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 ...


在Google群组中搜索（comp.lang.c）。讨论这个主题已经有了一些

的主题。


-

Morris Dovey

West Des Moines，爱荷华州美国

C链接在 http：/ /www.iedu.com/c

读我的嘴唇：苹果离树不远。

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.

Robert Vazan写道：

Robert Vazan wrote:

我正在寻找其他人尝试创建C的安全子集并使用脚本强制执行它。有没有人知道这样的事情？

通过安全，我的意思是：
*强类型的内存。无法将其重新解释为一堆字节
*从崩溃以外的无效和NULL指针中恢复
*可以通过不给它关键指针来隔离代码片段

使用的库支持这样的安全子集一定不能引入自己的缺陷。
例如，对于像Unix / Unix这样的指针使用int代理不是一个好主意，因为这允许指针猜测，因此
防止隔离。

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.

查看MISRA C指南， www.misra.org.uk ，这是可执行的

，带有类似商业lint的工具。你必须订购硬拷贝。我做了并且

发现它是一个有趣的读物。


但是，如果你真的对高完整性编码感兴趣，也许

像SPARK（Ada子集）这样的东西也可能让你感兴趣。


如果你坚持使用基于C语言的东西，MISRA-C就像VxWorks一样
安全关键系统
（ www.windriver.com ）可能是候选人，

取决于你要找的东西。

Mark F. Haigh
mf ***** @ sbcglobal.net

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*****@sbcglobal.net

2003年11月21日星期五13:47:49 +0100， Robert Vazan写道：

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

我正在寻找其他人尝试创建C的安全子集并使用脚本强制执行它。有没有人知道这样的事情？

通过安全，我的意思是：
*强类型的内存。无法将其重新解释为一堆字节

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

我发现这个要求几乎可以从远程相关的任何东西中删除你的
任务到C.

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

这篇关于C的安全子集？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！