guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scm_num2int change


From: Mikael Djurfeldt
Subject: Re: scm_num2int change
Date: 20 Sep 2001 20:26:42 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Bill Schottstaedt <address@hidden> writes:

> Where in "num" does it say "exact num"?

Where in "num" does it say "integer"? :)

> It also breaks existing Scheme code.

The following is a list of the Scheme procedures which, due to the
change in behavior of the integer conversion functions, has become
more restrictive in the sense that they no longer accept inexact
integers as arguments:

Procedure name          Argument affected

dynamic-call            1
dynamic-args-call       1
gethost                 1
getnet                  1
getproto                1
seek                    2
truncate-file           2
utime                   2,3
array-fill!             2
sigaction               2
setitimer               1-5
getitimer               1
htonl                   1
inet-ntoa               1
inet-netof              1
inet-lnaof              1
inet-makeaddr           1-2
inet-ntop               2
setsockopt              4
sendto                  4,5
localtime               1
gmtime                  1
struct-set!             3
uniform-array-set!      2
uniform-array-read!     3,4
uniform-array-write     3,4
open-fdes               2,3
open                    2
connect                 3
bind                    3
recvfrom!               3
integer-expt            2

I would argue that this is a gain in all cases except possibly for
integer-expt which I'll fix shortly.  (In each case, I've looked at
the code by hand and checked that it doesn't cause bugs.)

Apart from making it easier for the programmer to track down bugs,
this change makes some functions more consistent: Some of the
functions above use INUM conversions for some arguments and the
modified integer conversion functions for others.  The effect was that
those procedures didn't accept inexact integers in *some* arguments,
but did in others!  These cases now consistently demand exact values
for all arguments.

There are also a few internal uses of the functions which are OK as well.

Then we have the GH conversion functions, which also are affected:

gh_scm2int
gh_scm2ulong
gh_scm2long
gh_scm2longs

gh_scm2floats
gh_scm2doubles

Of these, the last two should use scm_num2float and scm_num2double
when these become available.

Best,
Mikael



reply via email to

[Prev in Thread] Current Thread [Next in Thread]