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 LAA24551; Thu, 8 Mar 2001 11:24:44 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA24462 for caml-list@pauillac.inria.fr; Thu, 8 Mar 2001 11:24:43 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA14611 for ; Wed, 7 Mar 2001 22:01:22 +0100 (MET) Received: from elbereth.pgh.arsdigita.com (fw1.pgh.arsdigita.com [63.124.128.66]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f27L1Lb29349 for ; Wed, 7 Mar 2001 22:01:21 +0100 (MET) Received: by elbereth.pgh.arsdigita.com (Postfix, from userid 1000) id 86D45AB9A; Wed, 7 Mar 2001 16:04:05 -0500 (EST) To: Dan Grossman Cc: caml-list@inria.fr Subject: Re: [Caml-list] bigarrays and toplevel on Win32? References: <4.3.2.7.2.20010304234009.00e1e220@shell16.ba.best.com> <20010305175715.B16895@pauillac.inria.fr> <87pufvoqro.fsf@elbereth.pgh.arsdigita.com> <3AA65B30.F354EA2@cs.cornell.edu> From: John Prevost In-Reply-To: <3AA65B30.F354EA2@cs.cornell.edu> Message-ID: <874rx52ucu.fsf@elbereth.pgh.arsdigita.com> User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/21.0.91 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: 07 Mar 2001 16:04:05 -0500 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >>>>> "dg" == Dan Grossman writes: dg> No. If I could be guaranteed a core dump on my first dg> out-of-bounds access, I would be fine with this. It's why my dg> C code sometimes doesn't check for null before dereferencing a dg> pointer. But with arrays, you can silently corrupt arbitrary dg> memory. Maybe your program crashes later. Maybe it ends up dg> deleting all your files. Maybe it never tells you that it dg> computed the wrong answer. dg> What I would be okay with was doing the bounds-check and dg> exiting (or core dumping if you prefer) on out-of-bounds. dg> This still gives an optimizer some leeway because dg> array-intensive code will have fewer exception-causing dg> instructions. You have a good point here--I was just being cheeky. I really look at the unsafe array operations as akin to the unsafe magic cast operation. None of them are appropriate for everyday use--but if I go over a small piece of code with a fine-toothed comb and prove to my satisfaction that everything is correct, it's worthwhile to have them. They're not the most ideologically sound tools available, but I appreciate that O'Caml tends to balance ideology with practicality more often than the other guys seem to. John. ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr