From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA10747; Fri, 30 Aug 2002 18:13:22 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA10996 for ; Fri, 30 Aug 2002 18:13:21 +0200 (MET DST) Received: from venus.is.s.u-tokyo.ac.jp (venus.is.s.u-tokyo.ac.jp [133.11.12.9]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g7UG3fD06317 for ; Fri, 30 Aug 2002 18:04:03 +0200 (MET DST) Received: from tuba.is.s.u-tokyo.ac.jp (tuba.is.s.u-tokyo.ac.jp [133.11.12.102]) by venus.is.s.u-tokyo.ac.jp (8.11.6/3.7W) with ESMTP id g7UG3FE03877; Sat, 31 Aug 2002 01:03:15 +0900 (JST) Received: (from oiwa@localhost) by tuba.is.s.u-tokyo.ac.jp (8.11.6+Sun/3.7W) id g7UG3Fk10303; Sat, 31 Aug 2002 01:03:15 +0900 (JST) X-Authentication-Warning: tuba.is.s.u-tokyo.ac.jp: oiwa set sender to oiwa@yl.is.s.u-tokyo.ac.jp using -f To: Vitaly Lugovsky Cc: J Farrand , David Frese , SooHyoung Oh , Caml-list Subject: Re: [Caml-list] Q: safe language References: From: Yutaka OIWA Date: 31 Aug 2002 01:03:15 +0900 In-Reply-To: Vitaly Lugovsky's message of "Fri, 30 Aug 2002 18:26:07 +0400 (MSD)" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk What a hot topic for me! :-) >> On Fri, 30 Aug 2002 18:26:07 +0400 (MSD), Vitaly Lugovsky 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"? Yes. 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. , 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