This is the mail archive of the newlib@sourceware.org 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 2016-03-20 07:35, Corinna Vinschen wrote:
On Mar 19 22:35, Yaakov Selkowitz wrote:
On 2016-03-19 12:10, Joel Sherrill wrote:
But now have:

#if __LARGEFILE_VISIBLE

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:

#if __LARGEFILE_VISIBLE || __POSIX_VISIBLE >= 200112

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)

The joys of conflicting documentation. -D_XOPEN_SOURCE=600 will get you _POSIX_C_SOURCE=200112L automatically, but -D_XOPEN_SOURCE=500 already gets you __USE_LARGEFILE (as, per feature_test_macros(7), _LARGEFILE_SOURCE is "implicitly defined if _XOPEN_SOURCE is defined with a value greater than or equal to 500"), so 500 would be more accurate here.

In any case, I'll post a patch for fseeko/ftello shortly.

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

This is the exception to the "-D_FILE_OFFSET_BITS=64 as no affect on 64-bit systems" rule; try compiling with -ansi and you should see they are not. Note that _POSIX_C_SOURCE=200809L is on by default, so maybe that's what you're seeing?

--
Yaakov


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