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 RAA07422; Wed, 7 Mar 2001 17:00:51 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 RAA07519 for ; Wed, 7 Mar 2001 17:00:50 +0100 (MET) Received: from sundown.cs.cornell.edu (sundown.cs.cornell.edu [128.84.96.20]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f27G0nj18081 for ; Wed, 7 Mar 2001 17:00:49 +0100 (MET) Received: from cs.cornell.edu (dhcp99-163.cs.cornell.edu [128.84.99.163]) by sundown.cs.cornell.edu (8.9.3/8.9.3/R-3.2) with ESMTP id LAA14194 for ; Wed, 7 Mar 2001 11:00:48 -0500 (EST) Message-ID: <3AA65B30.F354EA2@cs.cornell.edu> Date: Wed, 07 Mar 2001 11:00:48 -0500 From: Dan Grossman X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk John Prevost wrote: > > >>>>> "xl" == Xavier Leroy writes: > > xl> The party line on unsafe array accesses is unclear: on the one > xl> hand, we do not want to encourage their use, as it can break > xl> type safety and dramatically reduce the safety of the > xl> programs; on the other hand, they are handy when benchmarking > xl> against C or Fortran :-) > > Think of it less as an "unsafe array access" and more of "license to > turn a given set of exceptions into core dumps in exchange for > efficiency." ;) > > John. No. If I could be guaranteed a core dump on my first out-of-bounds access, I would be fine with this. It's why my C code sometimes doesn't check for null before dereferencing a pointer. But with arrays, you can silently corrupt arbitrary memory. Maybe your program crashes later. Maybe it ends up deleting all your files. Maybe it never tells you that it computed the wrong answer. What I would be okay with was doing the bounds-check and exiting (or core dumping if you prefer) on out-of-bounds. This still gives an optimizer some leeway because array-intensive code will have fewer exception-causing instructions. --Dan -- | Dan Grossman www.cs.cornell.edu/home/danieljg H:607 256 0724 | | 5157 Upson Hall danieljg@cs.cornell.edu O:607 255 9834 | ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr