Re: restrict

[Bruno Haible]

Hi Paul,

> > I'm after warnings that point to undefined behaviour, and since passing a
> > 'char *' in place of an 'unsigned char *', 'FILE *', or similar already
> > generates a compiler warning, using 'restrict' here does not offer an
> > advantage.
> 
> It can still offer an advantage, since GCC doesn't necessarily generate a 
> compiler warning without the 'restrict'. For example, in the following code 
> GCC 
> complains about the call to f but not the call to g:
> 
>    void f (char *restrict, int *restrict);
>    void g (char *, int *);
> 
>    int
>    main (void)
>    {
>      int      a[] = {0, 0, 0};
>      void *p = a;
>      f (p, p);
>      g (p, p);
>    }

True. But it's pretty rare that people use 'void *' pointers and cast them
to pointers of different types.

Also, even a small variation of this code does not produce a warning any more:

   void f (char *restrict, int *restrict);
   void g (char *, int *);

   int
   main (void)
   {
     int        a[] = {0, 0, 0};
     void *p = a;
     f (p, a);    // no warning!
     g (p, a);
   }

> More generally, the role of 'restrict' for optimizations can't be easily 
> separated from its role for warnings. Using 'restrict' to save machine 
> instructions also means that it's better for GCC to generate warnings when 
> the 
> behavior would otherwise be undefined; conversely, typically when GCC 
> generates 
> warnings it's free to optimize more. Because of this close connection, when 
> in 
> doubt it's better to use 'restrict' in a way that benefits optimization as 
> well 
> as warning.

It needs to be weighed against the desire not to produce warnings for valid
uses. For example here:

> >    int snprintf (char *str, size_t size, const char *format, ...);
> > ... since 'restrict' on the first parameter is going to signal a warning
> > for overlaps with the 3rd, 4th, 5th, ... parameter, we don't need 'restrict'
> > on the 3rd parameter.
> 
> If we omit 'restrict' from the 3rd parameter, GCC won't warn when the 3rd 
> parameter overlaps with the 4th. That's a minus.

Actually, GCC doesn't warn here, even with 'restrict', because the 3rd argument
is a const-pointer and the 4th argument, being variadic, is treated like a
const-pointer as well. Test case (enable one of the declarations):

#include <stddef.h>
//extern int smprintf (char *restrict, size_t, char *, ...);                    
            // no warning
//extern int smprintf (char *restrict, size_t, char *restrict, ...);            
            // warning
//extern int smprintf (char *restrict, size_t, const char *, ...);              
            // no warning
//extern int smprintf (char *restrict, size_t, const char *restrict, ...);      
            // no warning
//extern int smprintf (char *restrict, size_t, const char *restrict, char 
*restrict);       // warning
//extern int smprintf (char *restrict, size_t, const char *restrict, const char 
*restrict); // no warning

char buf[10];
int main ()
{
  char fmt[] = "%s";
  smprintf (buf, sizeof buf, fmt, fmt);
}

> This sounds backwards. Ordinarily (without restrict) there is a contract that 
> prevents the compiler from optimizing the implementation in certain ways. 
> With 
> restrict, that part of the contract goes away. From the programmer's point of 
> view, 'restrict' places additional restrictions on the caller, not on the 
> callee. And appropriate use of 'restrict' signals to programmers what the 
> callee 
> can do.

I agree.

> This signal to humans is useful regardless of whether tools like GCC use 
> the signal to generate warnings or optimizations.

I disagree. Given the confusion around what 'restrict' is actually about,
the "signal to humans" is fuzzy. As it stands, GCC >= 8 is the best bet for
a programmer to understand 'restrict'.

> > The "same array" rule comes from what I understood from various explanations
> > of 'restrict' on the web [1], and from what I see in the glibc headers for
> > functions that have multiple output parameters of the same type:
> >    - splice in <bits/fcntl-linux.h>,
> >    - printf_arginfo_size_function in <printf.h>,
> >    - openpty in <pty.h>,
> >    - re_set_registers in <regex.h>,
> >    - copy_file_range in <unistd.h>.
> 
> That stackoverflow explanation is full of confusing answers and none of them 
> are 
> particularly good. And the glibc headers evidently were not written by people 
> who cared about proper use of 'restrict' (possibly because they wrote the 
> headers before 'restrict' existed or was widely supported).

... possibly also because ISO C 99 § 6.7.3.1 is impenetrable.
... possibly also because GCC 8 was not around to teach the programmers.

> > But ecvt, fcvt in <stdlib.h> have 'restrict'. You may want to register a 
> > glibc
> > bug if you think these five functions should have 'restrict' :)
> 
> It's not a bug. It's required by POSIX (which uses 'restrict' more carefully) 
> in 
> its older editions. See:
> 
> https://pubs.opengroup.org/onlinepubs/009695399/functions/ecvt.html

I meant the "glibc bug" the other way around: Someone could tell the glibc 
people
that it makes sense to _add_ 'restrict' to the declarations of splice,
printf_arginfo_size_function, openpty, re_set_registers, copy_file_range.

Bruno