Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

language lawyering: ftello/fseek/pread edition



Petri Hintukainen pointed out a problem in the NetBSD headers about
ftello/fseeko/pread:

https://mailman.videolan.org/pipermail/libbdplus-devel/2015-March/000039.html

Can someone please fix the issue, or explain why the argument is wrong?

Thanks,
 Thomas

--- begin quote ---
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. Also, defining _POSIX_C_SOURCE is not optional.

> > > 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.

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.



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

Maybe we should use _NETBSD_SOURCE or _XOPEN_SOURCE ?
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
>>



----- End forwarded message -----


Home | Main Index | Thread Index | Old Index