This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RTEMS Targets Issue #2 - ftello()/fseeko()

On Mar 19 22:35, Yaakov Selkowitz wrote:
> On 2016-03-19 12:10, Joel Sherrill wrote:
> >We have a few files which get warnings because
> >ftello() and/or fseeko() are not prototyped.
> >These were protected by:
> >
> >#if !defined(__STRICT_ANSI__) || defined(__USE_XOPEN2K)
> Note that __USE_* is the glibc form of the internal macros, where newlib has
> (even prior to my changes) used the BSD form __*_VISIBLE.  So this was wrong
> to start with.
> >But now have:
> >
> >
> >The RTEMS fseeko() test does not explicitly define
> >__USE_XOPEN2K so I am guessing it was implicit before.
> >
> >Does the newlib guard need tinkering, the RTEMS default
> >features, or the test code in RTEMS?
> feature_test_macros(7) says that _XOPEN_SOURCE >= 500 includes these two
> largefile functions implicitly, but fseeko(3) says they are also
> POSIX.1-2001.  Does changing the guard to:
> fix this issue?

glibc's fseeko/ftello man page claims this guard:

   _FILE_OFFSET_BITS == 64 || _POSIX_C_SOURCE >= 200112L ||
   _XOPEN_SOURCE >= 600
   (defining the obsolete _LARGEFILE_SOURCE macro also works)

Note especially the _FILE_OFFSET_BITS == 64.  So fseeko/ftello are
always defined on systems with sizeof(off_t) == 8.


Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]