Re: newlib header breaks restricted pointers in C++

Curiosity killed the cat,
I might not understand, could you clarify. It mentions 'restrict is not 
a keyword in C++'.
So doesn't #if __cpplusplus need to define 'restrict'. Additionally, 
shouldn't the below mentioned
'#define'(s) include '__restrict__ ?

On Tue, Jul 25 2023 at 06:48:35 PM +0000, Corinna Vinschen 
<[email protected]> wrote:
> 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://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html>
>>  > >
>>  > > 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://gcc.gnu.org/gcc-2.95/c++features.html>
>>  > 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://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272723>
> 
> 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?
> 
> 
> Thanks,
> Corinna
>