Hi Mike and Seija,

On 11/27/22 13:00, Alejandro Colomar wrote:
> Hi,
> 
> On 11/27/22 12:44, Mike Frysinger via Libc-alpha wrote:
>> On 26 Nov 2022 19:56, Seija K. via Libc-alpha wrote:
>>> The format value has to be a string literal, every time. Otherwise, you are
>>> not using these functions correctly. To reinforce this fact, I put
>>> __restrict over every example of this I could find.
>>
>> there's at least some redundant settings in here that aren't needed.  for
>> example, the strptime prototype in time/time.h has restrict on fmt already,
>> so it isn't needed in time/strptime.c.
>> -mike
> 
> I just confirmed that neither clang(1) nor clang-tidy(1) emit any warnings (with 
> warnings to -Weverything and checks to *) at all if only the prototype has 
> restrict.  So yes, it seems redundant.

I've been thinking about this...  I changed my mind; I'm not neutral anymore 
about this.  I think it's better to add it, even if "redundant" to the compiler 
in most cases.

There are cases where it's not redundant:

$ cat restrict.c
void *f(int *restrict *restrict p, int *q);

void *f(int **p, int *q)
{
	return *p ?: q;
}

$ cc -Wall -Wextra restrict.c
restrict.c:3:7: error: conflicting types for ‘f’; have ‘void *(int **, int *)’
     3 | void *f(int **p, int *q)
       |       ^
restrict.c:1:7: note: previous declaration of ‘f’ with type ‘void *(int * 
restrict* restrict,  int *)’
     1 | void *f(int *restrict *restrict p, int *q);
       |       ^


This happens at least once in libc functions (although glibc differs from POSIX 
here), in lio_listio(3):

SYNOPSIS
        #include <aio.h>

        int lio_listio(int mode,
                       struct aiocb *restrict const aiocb_list[restrict],
                       int nitems, struct sigevent *restrict sevp);


So, the thing seems to be similar to 'const' being irrelevant for variables and 
pointers (but not pointees), which is why it is rarely used in function 
declarators.  When it is used, it only has a meaning in the function definition, 
since it makes the local variable const, but to the caller it's just noise, 
which is why it's never used in prototypes.

With 'restrict', the compiler seems to accept compatibility of types with the 
same rules, but this qualifier is meaningful to both the caller and the function 
definition.  In the prototype, it reminds the caller that the arguments should 
not alias, and maybe can help catch a few silly mistakes.  In the function 
definition, it reminds the implementor that it has some more freedom to 
implement the function.  So, even if it is redundant to the compiler, it is not 
to the programmer, and I think it would make sense to add a compiler warning 
that warns about mismatching restrict in function declarators.

For example, this would be nonsense (and I honestly don't know what the compiler 
would understand from it):

void broken(int *restrict a, int *b, int *c);
void broken(int *a, int *restrict b, int *c);

Does this mean that all parameters are really restrict?  That's the only logical 
conclusion in my head, but it is so braindead that it may just be implemented as 
UB.  A warning would be nice, to catch typos/thinkos while typing them.


Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>