From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9a586954b11ae008 X-Google-Attributes: gid103376,public From: Clayton Weaver Subject: Re: Overflows (lisp fixnum-bignum conversion) Date: 1997/04/05 Message-ID: #1/1 X-Deja-AN: 230917212 Sender: news@eskimo.com (News User Id) X-Nntp-Posting-Host: eskimo.com References: <1997Apr2.202514.1843@nosc.mil> Organization: Eskimo North (206) For-Ever Reply-To: Clayton Weaver Newsgroups: comp.lang.ada Originator: cgweav@eskimo.com Date: 1997-04-05T00:00:00+00:00 List-Id: (Is this nit-picking? Just a special case for the lisp fixnum to bignum conversion:) On Thu, 3 Apr 1997, Robert A Duff wrote: > Analogy: Suppose you write a signed integer expression that overflows. > In C, you get unpredictable results (exactly what Ada calls erroneous). > In Ada, you get a run-time error. In Lisp, you get the right answer. > It seems to me that, as far as preventing bugs goes, with respect to > this particular issue, C is worst, Ada is better (because it detects the > error), and Lisp is better still (because it prevents the error). > [Before somebody starts a three-way language war -- please note that I > said "with respect to this particular issue"!] Suppose the integer expression that overflows is used to determine the index size for an array allocation. Std lisp limits array indexes to fixnums. Lisp can transparently cast the overflowing representation from fixnum to bignum, but it will still error if it tries to allocate an array ("vector") with an index size beyond the fixnum bound, unless you have a custom handler for that case that either changes the array to some other storage type or virtualizes the data structure into an array of arrays, and sets a flag that whatever function accesses that array can read to change its lookup method. Regards, Clayton Weaver cgweav@eskimo.com (Seattle)