RE: newlib header breaks restricted pointers in C++

[Bruno De Fraine <Bruno.DeFraine@synopsys.com>]

Hello,

> -----Original Message-----
> From: Corinna Vinschen <vinschen@redhat.com>
> Sent: Tuesday, July 25, 2023 8:49 PM
> To: Sebastian Huber <sebastian.huber@embedded-brains.de>
> Cc: Bruno De Fraine <brunodf@synopsys.com>; newlib@sourceware.org
> Subject: Re: newlib header breaks restricted pointers in C++
> 
> On Jul 25 19:46, Sebastian Huber wrote:
> > On 25.07.23 19:35, Corinna Vinschen wrote:
> > > Hi Bruno,
> > >
> > > On Jul 24 22:23, Bruno De Fraine wrote:
> > > > Hello,
> > > >
> > > > As an extension, GCC and clang offer C99-style restricted pointers
> in C++ mode:
> > > > https://urldefense.com/v3/__https://gcc.gnu.org/onlinedocs/gcc/Res
> > > > tricted-Pointers.html__;!!A4F2R9G_pg!aU9wM3m354sF_hiGWy_vrFoJdVs4p
> > > > pL6L-vjcfOx3UOouh-kGDoXHt-F7WiaJmKbZ19ePhSowFxGrkp2kulDyOU$
> > > >
> > > > We notice that this extension is broken when including newlib
> headers: restricted pointers are treated as ordinary pointers.
> > > >
> > > > We traced this to the following section of
> newlib/libc/include/sys/cdefs.h:
> > > >
> > > >    /*
> > > >     * GCC 2.95 provides `__restrict' as an extension to C90 to
> support the
> > > >     * C99-specific `restrict' type qualifier.  We happen to use
> `__restrict' as
> > > >     * a way to define the `restrict' type qualifier without
> disturbing older
> > > >     * software that is unaware of C99 keywords.
> > > >     */
> > > >    #if !(__GNUC__ == 2 && __GNUC_MINOR__ == 95)
> > > >    #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901
> > > >    #define	__restrict
> > > >    #else
> > > >    #define	__restrict	restrict
> > > >    #endif
> > > >    #endif
> > > >
> > > > While the GCC __restrict extension was indeed introduced in GCC
> 2.95, it is not limited to this version; the extension is also not
> limited to C90:
> > > > https://urldefense.com/v3/__https://gcc.gnu.org/gcc-2.95/c**Afeatu
> > > > res.html__;Kys!!A4F2R9G_pg!aU9wM3m354sF_hiGWy_vrFoJdVs4ppL6L-vjcfO
> > > > x3UOouh-kGDoXHt-F7WiaJmKbZ19ePhSowFxGrkp2WBPU9ls$
> > > Either way, the above has been taken from FreeBSD, and it is still,
> > > as of today, the same expression as used in FreeBSDs sys/cdefs.h
> > > file.
> > >
> > > Seb, any input on this?
> >
> > I added a FreeBSD bug report:
> >
> > https://urldefense.com/v3/__https://bugs.freebsd.org/bugzilla/show_bug
> > .cgi?id=272723__;!!A4F2R9G_pg!aU9wM3m354sF_hiGWy_vrFoJdVs4ppL6L-vjcfOx
> > 3UOouh-kGDoXHt-F7WiaJmKbZ19ePhSowFxGrkp2HFg2w9c$
> 
> Great, thanks!  Do we want to wait for a FreeBSD solution, or do we want
> to change it now and, maybe, take the FreeBSD version later?
> 
> Does anybody want to provide a git compatible patch?

If the outcome is to fix this ahead of FreeBSD, I can send a git compatible patch, using the logic either from my suggestion or from Glibc (see elsewhere in this thread).
The differences between both are little:
- With gcc >= 2.95 and C99 (or newer) mode, you can choose whether to map to "restrict" or "__restrict" (this seems purely stylistic).
- It is possible to also check for clang since it supports the "__restrict" extension as well. But clang will define __GNUC__ macros to claim it is compatible with gcc 4.2.1 anyway. (AFAIK it has always done this, with that specific version, but more recently you can control this with the -fgnuc-version command-line option.)

Best regards,
Bruno De Fraine