Fixnums on 32-bit systems are 30 bits long, and are in the range -536870912 through 536870911. Fixnums on 64-bit systems are 61 bits long, and are in the range -1152921504606846976 through 1152921504606846975. (see Section 17.2.4, “Tagging scheme”)

Since we have much larger fixnums on 64-bit systems, INTERNAL-TIME-UNITS-PER-SECOND is 1000000 on 64-bit systems but remains 1000 on 32-bit systems. This enables much finer grained timing on 64-bit systems.

Darwin and MacOS X use HFS+ file systems by default; HFS+ file systems are usually case-insensitive. Most of Clozure CL's filesystem and pathname code assumes that the underlying filesystem is case-sensitive; this assumption extends to functions like EQUAL, which assumes that #p"FOO" and #p"foo" denote different, un-EQUAL filenames. Since Darwin/MacOS X can also use UFS and NFS filesystems, the opposite assumption would be no more correct than the one that's currently made.

Whatever the best solution to this problem turns out to be, there are some practical considerations. Doing:

? (save-application "DPPCCL")
	  

on 32-bit DarwinPPC has the unfortunate side-effect of trying to overwrite the Darwin Clozure CL kernel, "dppccl", on a case-insensitive filesystem.

To work around this, the Darwin Clozure CL kernel expects the default heap image file name to be the kernel's own filename with the string ".image" appended, so the idiom would be:

? (save-application "dppccl.image")
	  

MacOSX effectively supports two distinct line-termination conventions. Programs in its Darwin substrate follow the Unix convention of recognizing #\LineFeed as a line terminator; traditional MacOS programs use #\Return for this purpose. Many modern GUI programs try to support several different line-termination conventions (on the theory that the user shouldn't be too concerned about what conventions are used an that it probably doesn't matter. Sometimes this is true, other times ... not so much.

Clozure CL follows the Unix convention on both Darwin and LinuxPPC, but offers some support for reading and writing files that use other conventions (including traditional MacOS conventions) as well.

This support (and anything like it) is by nature heuristic: it can successfully hide the distinction between newline conventions much of the time, but could mistakenly change the meaning of otherwise correct programs (typically when files contain both #\Return and #\Linefeed characters or when files contain mixtures of text and binary data.) Because of this concern, the default settings of some of the variables that control newline translation and interpretation are somewhat conservative.

Although the issue of multiple newline conventions primarily affects MacOSX users, the functionality described here is available under LinuxPPC as well (and may occasionally be useful there.)

None of this addresses issues related to the third newline convention ("CRLF") in widespread use (since that convention isn't native to any platform on which Clozure CL currently runs). If Clozure CL is ever ported to such a platform, that issue might be revisited.

Note that some MacOS programs (including some versions of commercial MCL) may use HFS file type information to recognize TEXT and other file types and so may fail to recognize files created with Clozure CL or other Darwin applications (regardless of line termination issues.)

Unless otherwise noted, the symbols mentioned in this documentation are exported from the CCL package.

Despite what Darwin's man pages say, early versions of its math library (up to and including at least OSX 10.2 (Jaguar) don't implement single-precision variants of the transcendental and trig functions (#_sinf, #_atanf, etc.) Clozure CL worked around this by coercing single-precision args to double-precision, calling the double-precision version of the math library function, and coercing the result back to a SINGLE-FLOAT. These steps can introduce rounding errors (and potentially overflow conditions) that might not be present or as severe if true 32-bit variants were available.

Darwin/MacOS X distinguishes between "shared libraries" and "bundles" or "extensions"; Linux and FreeBSD don't. In Darwin, "shared libraries" have the file type "dylib" : the expectation is that this class of file is linked against when executable files are created and loaded by the OS when the executable is launched. The latter class - "bundles/extensions" - are expected to be loaded into and unloaded from a running application, via a mechanism like the one used by Clozure CL's OPEN-SHARED-LIBRARY function.