Re: [PATCH] man/: SYNOPSIS: Remove GNU forward-declarations of parameters for lengths of array parameters

[Alejandro Colomar <alx+linux-man@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3192 bytes --]

Hi Chris,

> Date: 2026-10-29 21:24:14+0000
> From: Christopher Bazley <chris.bazley.wg14@gmail.com>
>
[...]
> I don't want anything like this (fictitious) syntax:
> 
> bool ObjEditSelection_for_each_changed(ObjEditSelection const *a,
>   ObjEditSelection const *b,
>   _Optional MapArea const *map_area,
>   void callback[static](MapPoint, void *), void *cb_arg);

Indeed, me neither.  Just to clarify, this will still be disallowed by
my paper.

> What C actually needs is a standard extension to the direct declarator
> syntax to allow pointers to functions of qualified type.  Even
> disregarding _Optional, SDCC's __reentrant and __banked keywords would
> benefit from such standard syntax. SDCC currently has inconsistencies
> in this area, for example https://sourceforge.net/p/sdcc/bugs/3989/
> and https://sourceforge.net/p/sdcc/bugs/4027/

Also agree.  In fact, I believe [[reproducible]] should actually be a
_Reproducible function qualifier (actually, an anti-qualifier).  I plan
to work on a paper for that, but I need several things to happen first:

-  Non-access qualifiers to be standardized.  Several function
   qualifiers, to avoid annotating most functions, should be
   anti-qualifiers.

   I believe the paper about address-space qualifiers will help in this
   regard.

-  Type variance.  This is essential for backwards compatiblity.

> Although the keywords __reentrant and __banked appear syntactically in
> the position of a C23 attribute, I consider them type qualifiers
> rather than attributes because ignoring them can change the calling
> convention and make calls incorrect. They also participate in type
> checking:
> 
> int reentrant(int *) __reentrant;
> int banked(int *) __banked;
> int plain(int *);
> 
> int main(void)
> {
>     int (*r)(int *) __reentrant = reentrant;
>     r = plain; // how is this safe?
>     r = banked; // error
> 
>     int (*b)(int *) __banked = banked;
>     b = plain; // error
>     b = reentrant; // error
> 
>     int (*p)(int *) = plain;
>     p = reentrant;
>     p = banked; // error
> 
>     return 0;
> }
> https://godbolt.org/z/hPsxWe6Ga
> 
> I increasingly think this is also the right position for the qualifier
> in a declaration of a pointer to
> an optional function, e.g.
> 
> int (*o)(int *) _Optional = fn;
> 
> as a possible alternative to
> 
> _Optional typeof(int (int *)) *o = fn;

Also agree.  My idea was to have this:

	size_t strlen(const char *s) _Reproducible;

and collapse both attributes into a single qualifier.  We don't need
a tri-state, IMO.


Have a lovely night!
Alex

> Currently, type-qualifier-list appears after
> attribute-specifier-sequence in both alternatives for 'pointer'
> but not elsewhere it would be needed, such as after
> function-declarator in one of the alternatives for direct-declarator,
> nor after function-abstract-declarator in one of the alternatives for
> direct-abstract-declarator (which is where it would need to be
> permitted to allow qualified function type names to appear in casts).
> 
> Best regards,
> Christopher

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]