Re: Mismatch between newlib and glibc regarding fileno

Corinna Vinschen <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
On Feb 12 16:36, Torbjorn SVENSSON wrote:
> On 2024-02-09 17:54, Corinna Vinschen wrote:
> > On Feb  9 08:40, Andrew Pinski wrote:
> > > On Fri, Feb 9, 2024 at 8:30 AM Torbjorn SVENSSON
> > > <[email protected]> wrote:
> > > > 
> > > > Hi all,
> > > > 
> > > > I've been trying to run tests for arm-none-eabi on GCC14 tree.
> > > > What I've seen is that fileno() is not available. If you look though the
> > > > header files, I see that this is guarded by __POSIX_VISIBLE and due to a
> > > > recent change in the GCC testsuite (part of PR96395), they moved the
> > > > test case to gcc/testsuite/c-c++-common/analyzer/fileno-1.c and then
> > > > invoke it with g++ and -std=c++98. With this change, strict ANSI is
> > > > defined, but not __POSIX_VISIBLE.
> > > 
> > > Note the testcase failure is recorded as https://gcc.gnu.org/PR113278 .
> > > 
> > > > 
> > > > If I run the same test on the native g++ tool in Ubuntu, I instead get
> > > > that __USE_POSIX is set (the guard for fileno() in glibc), so this
> > > > differs from the behavior noticed with newlib.
> > > 
> > > That is also due to _GNU_SOURCE being defined for C++ for Linux/g++. I
> > > think this is just a GCC testcase issue rather than something needing
> > > to be fixed in newlib even.
> > 
> > Along these lines, note the Linux man page for fileno:
> > 
> >      STANDARDS
> >         POSIX.1-2008.
> > 
> >      HISTORY
> >        POSIX.1-2001.
> > 
> > and the feature test in GLibc's stdio.h:
> > 
> >      #ifdef  __USE_POSIX
> >      /* Return the system file descriptor for STREAM.  */
> >      extern int fileno (FILE *__stream) __THROW __wur;
> >      #endif /* Use POSIX.  */
> > 
> > 
> > Corinna
> > 
> Okay, so newlib is more restrictive than glibc on this topic.
> I will prepare a patch for test cases in GCC with defining _POSIX_SOURCE  so
> that the test cases succeed for newlib.

It looks like it.  But I do wonder if that's really intended by glibc.
I ran a quick test, first under newlibL

  $ g++ -std=c++98 -E -dM /usr/include/features.h | grep VISIBLE
  #define __LARGEFILE_VISIBLE 0
  #define __ISO_C_VISIBLE 1999
  #define __XSI_VISIBLE 0
  #define __GNU_VISIBLE 0
  #define __BSD_VISIBLE 0
  #define __POSIX_VISIBLE 0
  #define __SVID_VISIBLE 0
  #define __ATFILE_VISIBLE 0
  #define __MISC_VISIBLE 0

then under glibc:

  $ g++ -std=c++98 -E -dM x.cc | grep '#define __USE'
  #define __USE_UNIX98 1
  #define __USE_FORTIFY_LEVEL 0
  #define __USE_ISOC11 1
  #define __USE_ISOC95 1
  #define __USE_ISOC99 1
  #define __USE_XOPEN 1
  #define __USE_XOPEN2K 1
  #define __USE_POSIX199506 1
  #define __USE_GNU 1
  #define __USE_XOPEN2KXSI 1
  #define __USE_XOPEN2K8 1
  #define __USE_POSIX 1
  #define __USER_LABEL_PREFIX__ 
  #define __USE_MISC 1
  #define __USE_POSIX2 1
  #define __USE_LARGEFILE64 1
  #define __USE_POSIX199309 1
  #define __USE_XOPEN2K8XSI 1
  #define __USE_LARGEFILE 1
  #define __USE_XOPEN_EXTENDED 1
  #define __USE_DYNAMIC_STACK_SIZE 1
  #define __USE_ATFILE 1

How is it possible that with -std=c++98, everything and the kitchen sink
is enabled?  Is that really correct?!?


Corinna
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.