chicken-janitors
[Top][All Lists]
Advanced

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

[Chicken-janitors] [Chicken-bugs] #381: 64-bit number conversion on 32-b


From: Chicken Scheme
Subject: [Chicken-janitors] [Chicken-bugs] #381: 64-bit number conversion on 32-bit platforms sucks
Date: Fri, 30 Nov 2007 21:54:18 -0000

#381: 64-bit number conversion on 32-bit platforms sucks
-------------------------------------------------------+--------------------
 Reporter:  sjamaan                                    |       Owner:  felix
     Type:  defect                                     |      Status:  new  
 Priority:  major                                      |   Milestone:       
Component:  compiler                                   |     Version:  2.7  
 Keywords:  fixnums, flonums, numbers, 64-bit, 32-bit  |  
-------------------------------------------------------+--------------------
 When you have a 64-bit number that is returned on a 32-bit platform (for
 instance, when you call file-size), it is converted to a fixnum if it
 fits, otherwise it will return a flonum (because a double is bigger than
 an int).

 This means client code needs to build in lots of cruft dealing with the
 two situations.  This is very error-prone (especially when developing on
 64bits and deploying on 32bits) because fixnums can't just be replaced by
 flonums:

  * Printing flonums results in an unexpected trailing ".0" (this makes
 some http clients choke on the content-length header, for example)
  * flonums can't be used for indexing/specifying sizes of
 vectors/lists/whatever
  * flonums can't be passed to C bindings to functions that expect integers
  * Probably lots more I'm not thinking about right now (but that's the
 point!  It's unnecessarily unpredictable and adds complexity)

 Simply coercing flonums to fixnums in the above situations does not work
 because that will (or might, depending on the situation) result in
 overflow anyway.

 An option would be to provide a hook so the numbers egg can provide a
 graceful fallback when a number will not fit in a fixnum (however, what
 will happen when you pass this number to something that expects a fixnum?)

 There's still a need for proper behaviour when numbers is not available.
 My preference is raising an exception. It _is_ an exceptional situation
 when you can't fit a number in a fixnum while you're expecting it, so
 there's nothing wrong with that.  You can't do a whole lot useful stuff
 with the flonum anyway.  If a procedure expects/needs a fixnum, there's no
 way to convert the flonum anyway (since it didn't fit).

-- 
Ticket URL: <http://trac.callcc.org/ticket/381>
Chicken Scheme <http://www.call-with-current-continuation.org/>
The CHICKEN Scheme-to-C compiler

reply via email to

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