[libbdplus-devel] POSIX does not include fseeko/ftello

[Thomas Klausner]

Hi Petri!

Thanks for your reply.

On Fri, Mar 20, 2015 at 11:47:28AM +0200, Petri Hintukainen wrote:
> On ke, 2015-02-18 at 11:06 +0100, Thomas Klausner wrote:
> 
> Are you subscribed to the list ? (it took ~ month for your message to
> get thru)

No, I'm not subscribed. I just wanted to report a bug ;)

> > On Wed, Feb 18, 2015 at 10:56:09AM +0100, Thomas Klausner wrote:
> > > On Wed, Feb 18, 2015 at 10:28:39AM +0100, Jean-Baptiste Kempf wrote:
> > > > On 01 Feb, Thomas Klausner wrote :
> > > > > According to the NetBSD man page, fseeko and ftello conform to X/Open
> > > > > System Interfaces and Headers Issue 5 (``XSH5'').
> 
> Yes. POSIX-1.2001 (IEEE Std 1003.1-2001) was based on XHS5. According to Linux
> man pages (rel. 3.65) fseeko and ftello conform to POSIX.1-2001.
> 
> > > > > libbdplus tries to
> > > > > compile with -D_POSIX_C_SOURCE=200112L, which, on NetBSD, hides X/Open
> > > > > symbols that are not in POSIX, like fseeko and ftello.
> 
> The problem seems to be in NetBSD stdio.h.
> 
> From IEEE Std 1003.1-2001:
> 
> Base Definitions, chapter 13, stdio.h:
> <<
>    The following shall be declared as functions and may also be
>    defined as macros. Function prototypes shall be provided.
> ...
>    [CX]    int fseeko(FILE *, off_t, int);
>    [CX]    off_t ftello(FILE *);
> >>
> <<
>    CX Extension to the ISO C standard
>       The functionality described is an extension to 
>       the ISO C standard. Application writers may make
>       use of an extension as it is supported on all
>       IEEE Std 1003.1-2001-conforming systems.
> >>
> 
> System Interfaces, 2.2.1.1:
> <<
>    The _POSIX_C_SOURCE Feature Test Macro
>       A POSIX-conforming application should ensure that the feature
>       test macro _POSIX_C_SOURCE is defined before inclusion of any
>       header. When an application includes a header described by
>       IEEE Std 1003.1-2001, and when this feature test macro is
>       defined to have the value 200112L:
>       1. All symbols required by IEEE Std 1003.1-2001 to appear
>          when the header is included shall be made visible.
>       ...
> >>
> 
> So, unless I get it wrong (I didn't read full specs :) both functions
> are required in POSIX.1-2001 conforming stdio.h when _POSIX_C_SOURCE is
> 200112L.

I've discussed this on the NetBSD mailing list and there was agreement
with this statement, so I've fixed it in the NetBSD headers.

http://mail-index.netbsd.org/source-changes/2015/03/24/msg064236.html

> Also, defining _POSIX_C_SOURCE is not optional.

There was disagreement with this part though:

http://mail-index.netbsd.org/current-users/2015/03/23/msg026951.html

> > > > What define can we do to show them?
> > > 
> > > Is it an option to remove the define by default and only add it on Linux?
> > >
> > > I think this will also cause problems on other operating systems like
> > > Solaris, which also has the policy to restrict available symbols when
> > > a particular namespace is requested (in contrast to Linux, which adds
> > > symbols when a particular namespace is requested).
> 
> POSIX.1-2001 explicitly requires _POSIX_C_SOURCE macro to be defined.
> Not defining it may cause problems in other systems.

See above.

> To use these functions in linux we need one of following macros to be defined:
> _FILE_OFFSET_BITS == 64 || _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600
> 
> > Oh, another option would perhaps be to define _GNU_SOURCE which adds
> > symbols on Linux but is ignored everywhere else.
> 
> Not a good idea.
> 
> - _GNU_SOURCE would possibly change behavior for lots of
> POSIX-specified functions.
> 
> - We don't want to allow anything non-standard in the codebase.
> Adding _GNU_SOURCE would trigger endless loop of fixing non-standard
> extensions after every release.
> 
> Instead, we could add _NETBSD_SOURCE or _XOPEN_SOURCE ?
> That should fix the issue with NetBSD stdio.h.

I think defining _NETBSD_SOURCE is fine. Defining _XOPEN_SOURCE
usually introduces problems on Solaris (and sometimes NetBSD), since
that removes other symbols from the namespace there.

> While looking into this I noticed another possible problem with NetBSD:
> 
> Next libbluray release will use pread() from unistd.h. This function is
> an XSI extension in POSIX-1.2001, and mandatory in POSIX-1.2008.
> 
> from NetBSD unistd.h (I hope I used correct version ...):
> <<
> /*
>  * X/Open CAE Specification Issue 5 Version 2
>  */
> #if (_XOPEN_SOURCE - 0) >= 500 || defined(_NETBSD_SOURCE)
> ssize_t	 pread(int, void *, size_t, off_t);
> ssize_t	 pwrite(int, const void *, size_t, off_t);
> #endif
> >>
> 
> This is POSIX.1-2001 conforming (but not POSIX.1-2008 conforming)
> implementation of unistd.h

I've fixed this in the same commit.

> Maybe we should use _NETBSD_SOURCE or _XOPEN_SOURCE ?

As written above, I think _NETBSD_SOURCE is probably the better
solution (the headers will stay unfixed in NetBSD 5 and 6). If you go
with the _XOPEN_SOURCE definition, please test on Solaris.

Cheers,
 Thomas

> I think _XOPEN_SOURCE should fix both issues with NetBSD
> (and possibly with some other pre-POSIX.1-2008 systems).
> 
> from POSIX-1.2001:
> 
> <<
>   2.2.1.2 The _XOPEN_SOURCE Feature Test Macro
>   [XSI] An XSI-conforming application should ensure that the feature
>         test macro _XOPEN_SOURCE is defined with the value 600 before
>         inclusion of any header. This is needed to enable the
>         functionality described in Section 2.2.1.1 and in addition to
>         enable the XSI extension.
>         ...
> >>
> <<
>    XSI Extension
>        The functionality described is an XSI extension. Functionality
>        marked XSI is also an extension to the ISO C standard.
>        Application writers may confidently make use of an extension on
>        all systems supporting the X/Open System Interfaces Extension
> >>
> 
>