From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <63ea66f7ada7a4aaa994eb7a0dd0fbbf@terzarima.net> To: vester.thacker@gmail.com, 9fans@cse.psu.edu Subject: Re: [9fans] 64-Bit programming model. From: Charles Forsyth Date: Sat, 1 Oct 2005 15:20:33 +0100 In-Reply-To: <32a656c20509301427v79705106ta3c169660f5d59b6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: Topicbox-Message-UUID: 932c6250-ead0-11e9-9d60-3106f5b1d025 > 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.