English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Q: safe language
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-08-30 (16:13)
From: Yutaka OIWA <oiwa@y...>
Subject: Re: [Caml-list] Q: safe language
What a hot topic for me! :-)

>> On Fri, 30 Aug 2002 18:26:07 +0400 (MSD), Vitaly Lugovsky <vsl@ontil.ihep.su> said:

Vitaly> On Fri, 30 Aug 2002, J Farrand wrote:

Vitaly>  Ok, fixed. But I don't see any difference between segfault and NIL passed
Vitaly> as file descriptor. Program fails - and it does not matter, was it "low 
Vitaly> level" fault or unhandled exception or uncorrect behaviour.

No. SIGSEGV?  You are lucky.

You got SIGSEGV because an invalid pointer luckily points to the
outside of the process boundary. If it points to the inside of the
process, anything can be occur.  SIGSEGV, Malicious code injection,
clearing all your files, formatting your harddisk if you are a root,
and whatever else.

# SIGSEGV can be thought to be "safe" or "handled" if it is
# caused strictly by dereferencing "NULL" (or zero) in Unix environment.
# But many SIGSEGV are caused by buffer-overrun, dangling pointers, etc.
# Those are not safely handled.

The LISP exception you called it "unhandled" is actually handled.
It halts the program execution without relying to any luck.
It is defined to be so.

>> So for
>> example, C is not safe because you can derefence a bad pointer etc. and
>> cause a seg fault.

Vitaly>  Run C in a bytecode "safe" environment (there are some C implementations
Vitaly> with this functionality) - and it will become a "safe language"?


If there is no free(), no pointer arithmetic, no casting, no buffer overflow,
it is OK.
Malloc-free problem can be solved by GC.
Buffer overflow?  Check the boundary like Java.
Pointer arithmetics?  Use fat pointers.
Pointer cast (to/from void*)?  Hmm... but it can be done.

I and many other people are working on this problem.

But, we must be aware, if we say "C language is not safe", or
"Scheme is type-safe", we assume some "normal" implementation
of the language.  If we pass "-unsafe" option to ocamlc, it becomes
unsafe.  A mini-Scheme compilers which Junior students in our
department wrote as an assignment does not check '() in cdr function and 
thus not type safe.  If you use our "Fail-Safe ANSI-C compiler"
(sorry not yet finished), C language becomes type-safe.
But you expected those tricky answers?  I think you don't.

# In addition, "safety" depends on its definition.
# If we assume a machine language which has only the type "word",
# and assume every machine state is "OK", then the machine language is
# "type-safe". But this is also not what we want.
# We must share some "normal" interpretation of the "safe" or
# "type-safe" states.

Vitaly>  And C runtime environment can have a well defined behaviour of what to do 
Vitaly> with wrong pointers.

In usual way of compilation, it is not possible. It requires
some heavy changing of the way of compilation, which most people
think "unusual".

Yutaka Oiwa              Yonezawa Lab., Dept. of Computer Science,
      Graduate School of Information Sci. & Tech., Univ. of Tokyo.
      <oiwa@yl.is.s.u-tokyo.ac.jp>, <yutaka@oiwa.shibuya.tokyo.jp>
PGP fingerprint = C9 8D 5C B8 86 ED D8 07  EA 59 34 D8 F4 65 53 61
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners