* [C2x] Disallow function attributes after function identifier @ 2022-06-10 20:40 Alejandro Colomar 2022-06-10 21:09 ` Joseph Myers 2022-06-10 21:16 ` Jakub Jelinek 0 siblings, 2 replies; 11+ messages in thread From: Alejandro Colomar @ 2022-06-10 20:40 UTC (permalink / raw) To: Joseph Myers; +Cc: gcc [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [C2x] Disallow function attributes after function identifier 2022-06-10 20:40 [C2x] Disallow function attributes after function identifier Alejandro Colomar @ 2022-06-10 21:09 ` Joseph Myers 2022-06-10 21:35 ` Alejandro Colomar 2022-06-10 21:16 ` Jakub Jelinek 1 sibling, 1 reply; 11+ messages in thread From: Joseph Myers @ 2022-06-10 21:09 UTC (permalink / raw) To: Alejandro Colomar; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [C2x] Disallow function attributes after function identifier 2022-06-10 21:09 ` Joseph Myers @ 2022-06-10 21:35 ` Alejandro Colomar 0 siblings, 0 replies; 11+ messages in thread From: Alejandro Colomar @ 2022-06-10 21:35 UTC (permalink / raw) To: Joseph Myers; +Cc: gcc [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [C2x] Disallow function attributes after function identifier 2022-06-10 20:40 [C2x] Disallow function attributes after function identifier Alejandro Colomar 2022-06-10 21:09 ` Joseph Myers @ 2022-06-10 21:16 ` Jakub Jelinek 2022-06-10 21:31 ` Alejandro Colomar 1 sibling, 1 reply; 11+ messages in thread From: Jakub Jelinek @ 2022-06-10 21:16 UTC (permalink / raw) To: Alejandro Colomar; +Cc: Joseph Myers, gcc 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [C2x] Disallow function attributes after function identifier 2022-06-10 21:16 ` Jakub Jelinek @ 2022-06-10 21:31 ` Alejandro Colomar 2022-06-10 22:47 ` Jonathan Wakely 0 siblings, 1 reply; 11+ messages in thread From: Alejandro Colomar @ 2022-06-10 21:31 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Joseph Myers, gcc [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [C2x] Disallow function attributes after function identifier 2022-06-10 21:31 ` Alejandro Colomar @ 2022-06-10 22:47 ` Jonathan Wakely 2022-06-11 9:03 ` Alejandro Colomar 0 siblings, 1 reply; 11+ messages in thread From: Jonathan Wakely @ 2022-06-10 22:47 UTC (permalink / raw) To: Alejandro Colomar; +Cc: Jakub Jelinek, gcc, Joseph Myers 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/ > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [C2x] Disallow function attributes after function identifier 2022-06-10 22:47 ` Jonathan Wakely @ 2022-06-11 9:03 ` Alejandro Colomar 2022-06-11 12:08 ` Gabriel Ravier 2022-06-11 12:53 ` Jonathan Wakely 0 siblings, 2 replies; 11+ messages in thread From: Alejandro Colomar @ 2022-06-11 9:03 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Jakub Jelinek, gcc, Joseph Myers [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [C2x] Disallow function attributes after function identifier 2022-06-11 9:03 ` Alejandro Colomar @ 2022-06-11 12:08 ` Gabriel Ravier 2022-06-11 20:20 ` Alejandro Colomar 2022-06-11 12:53 ` Jonathan Wakely 1 sibling, 1 reply; 11+ messages in thread From: Gabriel Ravier @ 2022-06-11 12:08 UTC (permalink / raw) To: Alejandro Colomar, Jonathan Wakely; +Cc: Jakub Jelinek, gcc, Joseph Myers 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [C2x] Disallow function attributes after function identifier 2022-06-11 12:08 ` Gabriel Ravier @ 2022-06-11 20:20 ` Alejandro Colomar 2022-06-13 15:54 ` Jonathan Wakely 0 siblings, 1 reply; 11+ messages in thread From: Alejandro Colomar @ 2022-06-11 20:20 UTC (permalink / raw) To: Gabriel Ravier, Jonathan Wakely; +Cc: Jakub Jelinek, gcc, Joseph Myers [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [C2x] Disallow function attributes after function identifier 2022-06-11 20:20 ` Alejandro Colomar @ 2022-06-13 15:54 ` Jonathan Wakely 0 siblings, 0 replies; 11+ messages in thread From: Jonathan Wakely @ 2022-06-13 15:54 UTC (permalink / raw) To: Alejandro Colomar; +Cc: Gabriel Ravier, Jakub Jelinek, gcc, Joseph Myers 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [C2x] Disallow function attributes after function identifier 2022-06-11 9:03 ` Alejandro Colomar 2022-06-11 12:08 ` Gabriel Ravier @ 2022-06-11 12:53 ` Jonathan Wakely 1 sibling, 0 replies; 11+ messages in thread From: Jonathan Wakely @ 2022-06-11 12:53 UTC (permalink / raw) To: Alejandro Colomar; +Cc: Jakub Jelinek, gcc, Joseph Myers 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-06-13 15:54 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-06-10 20:40 [C2x] Disallow function attributes after function identifier Alejandro Colomar 2022-06-10 21:09 ` Joseph Myers 2022-06-10 21:35 ` Alejandro Colomar 2022-06-10 21:16 ` Jakub Jelinek 2022-06-10 21:31 ` Alejandro Colomar 2022-06-10 22:47 ` Jonathan Wakely 2022-06-11 9:03 ` Alejandro Colomar 2022-06-11 12:08 ` Gabriel Ravier 2022-06-11 20:20 ` Alejandro Colomar 2022-06-13 15:54 ` Jonathan Wakely 2022-06-11 12:53 ` Jonathan Wakely
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).