>> >> Attached is a patch that corrects the behaviour of >> C_i_foreign_[unsigned]_integer64_argumentp (there where bugs in both >> the signed and unsigned variant). > > Thanks! A question though: Shouldn't C_i_foreign_integer64_argumentp > also check that the flonum is an integer (ie, there's nothing after the > decimal point)?
It could. Should it? C just truncates. I dunno. > I think we should seriously consider supporting bignums in core. Argh. > They won't add much extra overhead in terms of optimizations I think quite the opposite is the case, but I'm usually wrong with my performance estimations. The only option is probably to try it out, which is a lot of hard work. > ; the scrutinizer > already needs to consider the possibility that a fixnum overflows into a > flonum. Overflowing into a bignum isn't much different. In fact, it's > slightly more precise because you know that they're always integral, > while you lose that information when switching to flonums. This at least > allows for some (admittedly trivial) optimizations you don't get when > using flonums, like knowing that integer? and exact? return true. I don't think that it adds many optimization options. > Besides, you won't lose information which helps srfi-4 64 bit types make > sense, and simplifies the part of the FFI currently under consideration. That is one case. It also _could_ simplify a lot of FFI code and handling of word-sized integers in general. I get cramps thinking of all the work that would have to go into such a project. cheers, felix _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
