fseek() vs. fseeko()
Wed Jun 20 10:52:00 GMT 2012
On Jun 19 13:28, Gregory Pietsch wrote:
> On 6/19/2012 1:11 PM, Corinna Vinschen wrote:
> >On Jun 19 18:27, Ralf Corsepius wrote:
> >>>Ok, then this is a bug in the RTEMS targets using 64-bit off_t.
> >>No. This is a bug in newlib.
> >>fseeko etc. are supposed to take abstract types "off_t".
> >>RTEMS relies upon this assumption, but obviously can't handle this.
> >>>Since> the fseeko64() etc. are non-standard this should be
> >>invisible for the> user.
> >>Agreed. They should not be used anywhere and be removed from newlib.
> >That's obviously not possible for backward compatibility.
> This makes me wonder about non-standard creep. Is there anything
> written with fseeko, fseeko8, fseeko16, fseeko32, fseeko64 or
> fseeko128 that could not be poosibly written with an appropriate
> fgetpos and fsetpos (the standard functions that deal with off_t)?
> Are those two functions substandard for what one tries to do?
What has that to do with backward compatibility? We have an exported
fseeko64 symbol which is only defined if __LARGE64_FILES is defined.
This method was used to allow 64 bit access while not breaking the
existing API. That's not something newlib invented or did without
precedent. Compare that with today's glibc stdio.h:
#if defined __USE_LARGEFILE || defined __USE_XOPEN2K
# ifndef __USE_FILE_OFFSET64
extern int fseeko (FILE *__stream, __off_t __off, int __whence);
extern __off_t ftello (FILE *__stream) __wur;
# ifdef __REDIRECT
extern int __REDIRECT (fseeko,
(FILE *__stream, __off64_t __off, int __whence),
extern __off64_t __REDIRECT (ftello, (FILE *__stream), ftello64);
# define fseeko fseeko64
# define ftello ftello64
There's an analogue expression for fgetpos/fsetpos.
If we want to make sure that fseeko/ftello/fgetpos/fsetpos always
do the "right thing", we have to do it while maintaining backward
compatibility. Glibc apparently does so as well.
Cygwin Project Co-Leader
More information about the Newlib