[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: largefile64 on ports
From: |
Kevin Ryde |
Subject: |
Re: largefile64 on ports |
Date: |
Mon, 11 Sep 2006 10:43:02 +1000 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
Greg Troxel <address@hidden> writes:
>
> it still seems really gross to impose the two
> sets of calls, esp. in 2006 when the transitional API should have been
> transitioned already ...
"Tell him he's dreamin"
-- Dale Kerrigan :-)
Transition is probably do-able in a source based dist, but for
binaries it'd be bad to change the size of a basic type. My guess
would be that it's too late and gnu/linux on 32-bit systems won't
change, leaving one to cope with the two flavours of calls.
> I think your patch does that;
> if there are no foo64 syscalls then foo is used, and with off_t, so
> things should be fine. Am I following correctly?
Yes. And if the 64 calls exist and are just aliases for the plain
ones, then that works too.
> _LARGEFILE64_SOURCE doesn't show up in the SUS document
Section 3.3.2 "Compilation Environment - Visibility of Transitional
API", I think.
> I
> think 4.4BSD chose to just make off_t 64-bit and skip the transitional
> API. In retrospect that was clearly the right move - all this pain is
> simply skipped, and old programs run fine. But I realize that's not
> the question on the table.
Yep. I guess glibc or the linux kernel (or both, or whichever came
first) went the SVR4 way. (I couldn't spot an off_t spec in the SRV4
ABI manuals, I suppose some of that stuff goes right back to when
seek() and friends used "long".)