Mon, 15 Jan 2001 16:24:54 -0800
On Tue, Jan 16, 2001 at 12:55:36AM +0100, Thomas Wouters wrote:
> On Mon, Jan 15, 2001 at 02:10:26PM -0800, Trent Mick wrote:
> > The problem is that these systems lie when they "say" (according to
> > Python's configure tests for HAVE_LARGEFILE_SUPPORT) that they have
> > largefile support. This seems to have happened for a particular release of
> > BSD (which has since been fixed). I think that the Right(tm) (meaning the
> > cleanest solution where the tests and definitions in the code actually
> > represent the truth) answer is a proper configure test (sort of as Greg
> > suggests). I don't really feel comfortable writing that patch (because (1)
> > lack of time and (2) inability to test, I don't have any access to any of
> > these BSD machines).
> There is no (longer any) 'single BSD release', so I doubt it has 'since been
> fixed' :)
Okay sure (showing my ignorance). My only understanding was that this
"lying" was the case for some unspecified BSDs a while ago but that the
latest releases of any of them *did* have largefile support.
> I tried to fix the test, but I have been completely unable to find a proper
> test. There doesn't seem to be a 'standard' one, and I wasn't able to figure
> out what, say, 'zsh' uses -- black autoconf magic, for sure.
Hmmm... if one code encode whether or not a 64-bit fseek could be
implemented (either using fseek, fseek0, fseek64, _fseek, fsetpos/fgetpos,
etc.) in a short C program then that would be the test (or at least most of
the test, might have to see if ftell could be implemented as well). Or are
there other requirements?