Eric Blake writes:
>
> According to Larry Jones on 12/14/2007 12:25 PM:
> > Eric Blake writes:
> >> maybe it's at least worth adding a compile-time assertion that
> >> sizeof(off_t)
> >> ==sizeof(long) when !HAVE_FSEEKO.
> >
> > Since I actually have a platform where that's not the case, I'd prefer a
> > run-time test that only objects when there's an actual problem:
>
> Which platform?
BSD/OS 4.2
> And is there a ChangeLog entry for your patch?
2007-12-14 Larry Jones <[EMAIL PROTECTED]>
* lib/fseeko.c (rpl_fseeko): Don't refuse to compile when no native
fseeko and off_t bigger than long but fail if the offset is too big.
> Does the platform lseek actually respect off_t?
Yes, it does.
> I still find it strange that there would not be an fseeko when the
> platform is capable of larger-than-long file offsets.
As I recall, POSIX had already defined lseek using off_t prior to the
Large File Summit that defined ftello and fseeko, so it was a simple
matter to define off_t as an extended type (quad_t), but there wasn't
any simple fix for the stdio library.
> But given your claim, it looks like you are correct that we
> are stuck with adding overflow checking in that case, and likewise for
> ftello.
Well, like I said before, BSD/OS, although very popular at one time, is
now quite thoroughly defunct, so I wouldn't go to too much trouble just
for it. I don't mind not having working large file support, but I'd
like to be able to at least build code that uses gnulib fseeko and have
it work on regular files.
> But can we at least avoid compiler warnings for platforms where
> off_t is the same size as long, such that this condition can never be true?
>
> > + else if (offset < LONG_MIN || offset > LONG_MAX)
I don't know of any good way to do that since you can't use sizeof in
the preprocessor and there's no standard limit macro for off_t that I
know of. Suggestions?
-Larry Jones
I take it there's no qualifying exam to be a Dad. -- Calvin
