> Sorry, I forgot to mention the article that led to my earlier
> question: http://www.unix.org/version2/whatsnew/lp64_wp.html
yes, i know that one. i don't understand why they so glibly assert that
approach is easier, unless they hadn't done enough experimental work,
or they were unreasonably fortunate in the body of code they picked.
i think there might be a discussion about this wrt plan 9 in the archives.
briefly, i tried LP64 first, because of the pointer<->int and system interface
points they make,
but in fact--that is to say i found out about it by actually trying it on plan
9, ape and
other source code--and not just on plan 9, much existing software
assumes in subtle ways that long is 32 bits.
that's unsurprising given the history of the type (eg, when int was 16 bits).
plain `int' tends to be used when no particularly large range is needed.
plan 9 code (like pre-LP64 unix code) already uses long long for 64 bits.
in fact, one could argue that the LLP64 forces one to consider
- how best to write pointer<->int conversions or whether they can be
avoided
- details of the syscall interfaces that anyway need thought with the
move to 64 bits
(eg, to retain portability between 32- and 64-bit architectures)
as to the latter: when plan 9 changed to 64 bit file sizes and offsets, the
interface changed. full stop.
various unix systems (i think freebsd is an unusual exception) fussed about
trying
to preserve both 32- and 64-bit interfaces, with too many
#ifdefs and `feature macro' definitions, and the result is a Big Frustrating
Mess.
