> Date: Sat, 11 Jan 2003 11:00:57 +0100 > From: Guido Draheim <[EMAIL PROTECTED]>
> > It's just like you shouldn't mix x86 applications with sparc > > libraries. They're different flavors of executable code. Don't try > > to link them together. > > Well, the linker would tell you in this example Then fix your linker so that it also tells you about off_t linkage screwups. But don't contort every other tool in the toolchain to add support for misconfigured programs. > The end of the discussion can only be to change the compilation > behaviour globally - making 64bit off_t the default if that is > supported by the system, and dropping the settable off_t altogether. Yes, that's the only sane solution. And it's the solution we should be striving for. We should not waste our time trying to support mixed 32- and 64-bit chimeras. One good way to head in that direction is to make 64-bit off_t the default, with 32-bit off_t available only by explicit request. POSIX allows this behavior, and I don't see why more people don't do it that way these days. > let the application maker call explicitly the func64 > symbols and off64_t type if that is supposed to be the intent. No, no, that is a misguided approach. Applications and libraries should be written portably, and should work regardless of the width of off_t. Applications should work even if off_t is 128 bits. It is a mistake to hardwire off64_t, fseek64, etc., into applications and libraries. They are meant only for temporary conversions in closed-source applications (e.g., you have a 32-bit 3rd-party library that you can't recompile). They have little real utility in the open-source world.
