Re: restrict

[Paul Eggert]

On 2/16/20 3:49 PM, Bruno Haible wrote:

> 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);
  }

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.

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

> I mean any possible implementation, compiled from the code we have in gnulib.
> 'restrict' is part of the contract between the caller of the function and the
> implementation of the function. When the compiler optimizes the implementation,
> it has to stick to the contract.

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. This signal to humans is useful regardless of whether tools like GCC use 
the signal to generate warnings or optimizations.
> 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).

> 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

The functions in questions have been withdrawn from POSIX; if they had not been, 
the 'restrict's would still be there.