# [plt-scheme] Re: v300 on OpenBSD

Matthew Flatt writes:
>* The v300 OpenBSD problem turned out to be a bad equal-hash function for
*>* inexact numbers in the case of +inf.0, -inf.0, or +nan.0.
*>*
*>* The problem showed up when compiling parser-tools because the lexer
*>* generator (run at compile time) uses an equal-based hash table with
*>* keys that contain +inf.0. I don't know why the problem showed up only
*>* with OpenBSD (and closely related systems).
*
Luck, apparently. The value of the integer returned-by-pointer from
frexp is, according to both the Open Group and a comment in FreeBSD's
source, unspecified in the case of infinity or NaN. FreeBSD chooses
to leave the value unchanged from what it was on entry, while the
implementation used in NetBSD and OpenBSD will set it to 0.
Glibc's is... written in assembly, and the one for 386/387 is largely
uncommented. There are limits to my curiosity.
--
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l)))))) (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k))))))) '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))