[C2x] Disallow function attributes after function identifier

[C2x] Disallow function attributes after function identifier

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2186 bytes --]

Hi, Joseph!

I'd like to suggest a change in C2x regarding attributes.

Right now, the draft allows function attributes to go right at the 
beginning of a function prototype, or just before the opening parenthesis:

[[attr]] type f(params);
type f [[attr]](params);

I'd argue against the second one, for the following reasons:

C programmers are used to the "f(...)" notation so much that it would be 
a bit confusing to change that.

See for example a linux-man@ discussion: 
<https://lore.kernel.org/linux-man/d015464c-714d-771e-6829-c1032efab15d@cs.ucla.edu/T/#u>.

Not only that, but it's common practise to hide attributes in macros, as in:

#if __STDC_VERSION__ > 201710L
#define my_inline [[gnu::always_inline]]
#else
#define my_inline __attribute__((__always_inline__))
#endif

Now see a valid C2x function prototype:

my_inline type f(params);
type f my_inline(params);

I hope no-one will ever write that code, even if ISO C ever allows it, 
but I'd rather see ISO C to forbid that aberration.

And, as much as that becomes human unreadable, it also makes it 
impossible for simple utils to parse C code.

I'm writing a PCRE-based tool that finds declarations and definitions 
within source code repositories.  It's already quite good, if we take 
into account it's simplicity.  Since it doesn't involve anything close 
to a compiler, it can only make a best guess, based on the assumption 
that the code follows some sane coding style.  For example, the PCRE 
regex for finding a function prototype is

 
'(?s)^[\w[]([\w\s\(,\)[\]*]|::)+[\w\s\)*\]]\s+\**'"$1"'\s*\(([\w\s\(,\)[\]*]|::)+?(\.\.\.)?\)([\w\s\(,\)[\]]|::)*;'

See the whole program (sh(1) script): 
<http://www.alejandro-colomar.es/src/alx/alx/grepc.git/>

That would be completely broken if anything could go after the function 
identifier.

So, could you please drop that from C2x?


Cheers,

Alex


P.S.: The latest draft that I know of is N2731.  I guess there are newer 
ones.  Could you please name the latest one?

-- 
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

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

Re: [C2x] Disallow function attributes after function identifier

[Joseph Myers]

On Fri, 10 Jun 2022, Alejandro Colomar via Gcc wrote:

> I'd like to suggest a change in C2x regarding attributes.

The attribute syntax is supposed to accept attributes in exactly the 
places they are accepted in C++ (and appertaining to the same entity, for 
each such place), for constructs present in both C and C++; it wouldn't be 
appropriate to diverge.

> P.S.: The latest draft that I know of is N2731.  I guess there are newer ones.
> Could you please name the latest one?

It's N2912 (June 8 version - the version originally published on June 7 
had various problems; there are still some issues, especially in Annex H, 
that have been fixed since the June 8 version, but fewer than in the June 
7 version).  As far as I know, N2912 incorporates all changes accepted so 
far for C23; the deadline for final versions of ongoing proposals to be 
considered at the July meeting is 17 June (and the July meeting is the 
deadline for new features to get in before the CD ballot).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [C2x] Disallow function attributes after function identifier

[Jakub Jelinek]

On Fri, Jun 10, 2022 at 10:40:15PM +0200, Alejandro Colomar via Gcc wrote:
> So, could you please drop that from C2x?

No!

For one it diverges from C++, but also it means something different
at the different locations.
[[attr0]] void foo (void), bar (void);
appertains to both declarations, while
void baz [[attr1]] (void), qux [[attr2]] (void);
appertains to only the specific declaration.
void corge (void) [[attr3]];
appertains to the function type.

	Jakub

Re: [C2x] Disallow function attributes after function identifier

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1449 bytes --]

[I reordered some of your answers, to better answer]

Hi Jakub,

On 6/10/22 23:16, Jakub Jelinek wrote:
> On Fri, Jun 10, 2022 at 10:40:15PM +0200, Alejandro Colomar via Gcc wrote:
>> So, could you please drop that from C2x?
> 
> No!



> [[attr0]] void foo (void), bar (void);
> appertains to both declarations, while

True, but.

> void baz [[attr1]] (void), qux [[attr2]] (void);
> appertains to only the specific declaration.

That's true.  But how many of these are spotted in the wild, 
non-theoretical world?

In the world I live, they mean effectively (but not theoretically) the 
same thing :)


> void corge (void) [[attr3]];
> appertains to the function type.

Yes, that one is clear.



 >
 > For one it diverges from C++, but also it means something different
 > at the different locations.

Well, I'd argue the same reasons to remove it from C++.  Don't know how 
useful that feature is for C++, though.  I bet not much, but am not an 
expert in the language.

But, are we sure we want to add this to C?  You know how difficult is to 
revert mistakes in C, as opposed to C++, where additions and 
deprecations are more common.

This is basically breaking any ability to separately (textually) parse C 
files without the build context.


Regards,

Alex


-- 
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

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

Re: [C2x] Disallow function attributes after function identifier

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 886 bytes --]

Hi Joseph,

On 6/10/22 23:09, Joseph Myers wrote:
>> P.S.: The latest draft that I know of is N2731.  I guess there are newer ones.
>> Could you please name the latest one?
> 
> It's N2912 (June 8 version - the version originally published on June 7
> had various problems; there are still some issues, especially in Annex H,
> that have been fixed since the June 8 version, but fewer than in the June
> 7 version).  As far as I know, N2912 incorporates all changes accepted so
> far for C23; the deadline for final versions of ongoing proposals to be
> considered at the July meeting is 17 June (and the July meeting is the
> deadline for new features to get in before the CD ballot).
> 

Thanks!  Will update my links :)

Cheers,

Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

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

Re: [C2x] Disallow function attributes after function identifier

[Jonathan Wakely]

On Fri, 10 Jun 2022, 22:29 Alejandro Colomar via Gcc, <gcc@gcc.gnu.org>
wrote:

> [I reordered some of your answers, to better answer]
>
> Hi Jakub,
>
> On 6/10/22 23:16, Jakub Jelinek wrote:
> > On Fri, Jun 10, 2022 at 10:40:15PM +0200, Alejandro Colomar via Gcc
> wrote:
> >> So, could you please drop that from C2x?
> >
> > No!
>
>
>
> > [[attr0]] void foo (void), bar (void);
> > appertains to both declarations, while
>
> True, but.
>
> > void baz [[attr1]] (void), qux [[attr2]] (void);
> > appertains to only the specific declaration.
>
> That's true.  But how many of these are spotted in the wild,
> non-theoretical world?
>
> In the world I live, they mean effectively (but not theoretically) the
> same thing :)
>
>
> > void corge (void) [[attr3]];
> > appertains to the function type.
>
> Yes, that one is clear.
>
>
>
>  >
>  > For one it diverges from C++, but also it means something different
>  > at the different locations.
>
> Well, I'd argue the same reasons to remove it from C++.  Don't know how
> useful that feature is for C++, though.  I bet not much, but am not an
> expert in the language.
>

It's used in libstdc++ because I couldn't get an attribute to work in any
other location, because it isn't valid at other positions in a constrained
function template. So no, we can't remove it from C++.




> But, are we sure we want to add this to C?  You know how difficult is to
> revert mistakes in C, as opposed to C++, where additions and
> deprecations are more common.
>

To the core language grammar? Are you sure about that?



> This is basically breaking any ability to separately (textually) parse C
> files without the build context.
>
>
> Regards,
>
> Alex
>
>
> --
> Alejandro Colomar
> Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
> http://www.alejandro-colomar.es/
>

Re: [C2x] Disallow function attributes after function identifier

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2696 bytes --]

Hi Jonathan,

On 6/11/22 00:47, Jonathan Wakely wrote:
>     Well, I'd argue the same reasons to remove it from C++.  Don't know how
>     useful that feature is for C++, though.  I bet not much, but am not an
>     expert in the language.
> 
> 
> It's used in libstdc++ because I couldn't get an attribute to work in 
> any other location, because it isn't valid at other positions in a 
> constrained function template. So no, we can't remove it from C++.
> 

Hmm, okay, not removable in C++.  I'm curious about the specific line of 
code, if you have it around and could link to it.  But C++ is huge, so 
anything is to be expected :)

> 
> 
> 
>     But, are we sure we want to add this to C?  You know how difficult
>     is to
>     revert mistakes in C, as opposed to C++, where additions and
>     deprecations are more common.
> 
> 
> To the core language grammar? Are you sure about that?

Well, everything is relative.

libstdc++ additions, deprecations (and undeprecations) are much more 
common than in the core C++ language (e.g., the deprecation and later 
undeprecation of <std*.h> headers).

But breaking changes in the core C++ language are still more common than 
in C, where (sadly) we still have the useless 'auto' for backwards 
compatibility with dead languages, which would be nice in macros with 
the meaning of __auto_type.  Maybe in the 2050s?  :P


So, C++ needs this feature.

Then in C, we don't need it (I've never seen code reusing the return 
type to declare more than one function, and I hope to never see that 
apart from theoretical investigation).  `int foo(void), bar(void);` 
seems a useless feature in the language to me, but maybe disallowing it 
through an exception to the rules would complicate the wording more than 
help, so if that's kept in the language, I'm fine with it.

So we could, and also could not, bring the C++ attribute for that 
useless feature.

In C, I don't think that attribute position can have a useful use case 
that can't be achieved by an attribute at the start of the prototype, 
since the language is much simpler.

Do we want to add a completely unnecessary feature, just for symmetry 
with C++, even if it poses a danger of breaking (both human and script) 
readability of function declarations/definitions, especially when hidden 
in macros?


I still have the hope that if the feature is finally kept in C23, 
absolutely no-one will ever use it, but then I question the introduction 
in the first place.


Cheers,

Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

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

Re: [C2x] Disallow function attributes after function identifier

[Gabriel Ravier]

On 6/11/22 11:03, Alejandro Colomar via Gcc wrote:
 > Hi Jonathan,
 >
 > On 6/11/22 00:47, Jonathan Wakely wrote:
 >>     Well, I'd argue the same reasons to remove it from C++.  Don't 
know how
 >>     useful that feature is for C++, though.  I bet not much, but am 
not an
 >>     expert in the language.
 >>
 >>
 >> It's used in libstdc++ because I couldn't get an attribute to work 
in any other location, because it isn't valid at other positions in a 
constrained function template. So no, we can't remove it from C++.
 >>
 >
 > Hmm, okay, not removable in C++.  I'm curious about the specific line 
of code, if you have it around and could link to it. But C++ is huge, so 
anything is to be expected :)
 >
 >>
 >>
 >>
 >>     But, are we sure we want to add this to C?  You know how difficult
 >>     is to
 >>     revert mistakes in C, as opposed to C++, where additions and
 >>     deprecations are more common.
 >>
 >>
 >> To the core language grammar? Are you sure about that?
 >
 > Well, everything is relative.
 >
 > libstdc++ additions, deprecations (and undeprecations) are much more 
common than in the core C++ language (e.g., the deprecation and later 
undeprecation of <std*.h> headers).
 >
 > But breaking changes in the core C++ language are still more common 
than in C, where (sadly) we still have the useless 'auto' for backwards 
compatibility with dead languages, which would be nice in macros with 
the meaning of __auto_type.  Maybe in the 2050s?  :P
 >
 >
 > So, C++ needs this feature.
 >
 > Then in C, we don't need it (I've never seen code reusing the return 
type to declare more than one function, and I hope to never see that 
apart from theoretical investigation).  `int foo(void), bar(void);` 
seems a useless feature in the language to me, but maybe disallowing it 
through an exception to the rules would complicate the wording more than 
help, so if that's kept in the language, I'm fine with it.
 >
 > So we could, and also could not, bring the C++ attribute for that 
useless feature.
 >
 > In C, I don't think that attribute position can have a useful use 
case that can't be achieved by an attribute at the start of the 
prototype, since the language is much simpler.
 >
 > Do we want to add a completely unnecessary feature, just for symmetry 
with C++, even if it poses a danger of breaking (both human and script) 
readability of function declarations/definitions, especially when hidden 
in macros?

I actually don't get the trouble with this. Your tool already can't 
parse declarations if they don't follow a certain coding style, so you 
can just add this restriction to the coding style that's required.

 > I still have the hope that if the feature is finally kept in C23, 
absolutely no-one will ever use it, but then I question the introduction 
in the first place.

Well in the same way, `int long signed const typedef long x;` is valid 
C, and I do hope that nobody will ever use it, but I don't think we 
should change C's grammar to disallow it.

 >
 > Cheers,
 >
 > Alex
 >

Cheers,

Gabriel

Re: [C2x] Disallow function attributes after function identifier

[Jonathan Wakely]

On Sat, 11 Jun 2022, 10:00 Alejandro Colomar, <alx.manpages@gmail.com>
wrote:

> Hi Jonathan,
>
> On 6/11/22 00:47, Jonathan Wakely wrote:
> >     Well, I'd argue the same reasons to remove it from C++.  Don't know
> how
> >     useful that feature is for C++, though.  I bet not much, but am not
> an
> >     expert in the language.
> >
> >
> > It's used in libstdc++ because I couldn't get an attribute to work in
> > any other location, because it isn't valid at other positions in a
> > constrained function template. So no, we can't remove it from C++.
> >
>
> Hmm, okay, not removable in C++.  I'm curious about the specific line of
> code, if you have it around and could link to it.  But C++ is huge, so
> anything is to be expected :)
>

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/ranges_base.h;h=38db33fd2ce9ea4c2a2a11035e09f41ba008515c;hb=HEAD#l111

Re: [C2x] Disallow function attributes after function identifier

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1817 bytes --]

On 6/11/22 14:08, Gabriel Ravier wrote:

>  > Do we want to add a completely unnecessary feature, just for symmetry 
> with C++, even if it poses a danger of breaking (both human and script) 
> readability of function declarations/definitions, especially when hidden 
> in macros?
> 
> I actually don't get the trouble with this. Your tool already can't 
> parse declarations if they don't follow a certain coding style, so you 
> can just add this restriction to the coding style that's required.

True-ish.  But when I mean that my tool requires a same coding style, I 
mean that it just requires that the code hasn't been written by some 
monkey.  Things that are not correctly parsed by my tool are of this kind:

int foo(void)
  {
      return 7;
      }

or

#define empty

int foo empty(void)
{
     return 42;
}

Modulo errors in the regexes, any rational indentation is supported 
(except for K&R definitions, which are also impossible to parse with a 
regex, but ISO C deprecated them a long time ago).

> 
>  > I still have the hope that if the feature is finally kept in C23, 
> absolutely no-one will ever use it, but then I question the introduction 
> in the first place.
> 
> Well in the same way, `int long signed const typedef long x;` is valid 
> C, and I do hope that nobody will ever use it, but I don't think we 
> should change C's grammar to disallow it.

Fair point :)


Cheers,

Alex


P.S.: Please consider deprecating 'auto' some day.  It would be nice to 
see C++'s auto in ISO C some day, even if it's 2060.  I'm not entirely 
happy doing `#define auto __auto_type` (of course it's UB, but it's nice) ;)


-- 
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

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

Re: [C2x] Disallow function attributes after function identifier

[Jonathan Wakely]

On Sat, 11 Jun 2022 at 21:17, Alejandro Colomar wrote:
> P.S.: Please consider deprecating 'auto' some day.  It would be nice to
> see C++'s auto in ISO C some day, even if it's 2060.  I'm not entirely
> happy doing `#define auto __auto_type` (of course it's UB, but it's nice) ;)

There's a proposal, but it leaves it open whether to standardize it as
"auto" or "__auto_type".

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2953.htm