[C2x] Disallow function attributes after function identifier

[Alejandro Colomar via Gcc]

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


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): 



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/


OpenPGP_signature
Description: OpenPGP digital signature

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
jos...@codesourcery.com

Re: [C2x] Disallow function attributes after function identifier

[Jakub Jelinek via 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

Re: [C2x] Disallow function attributes after function identifier

[Alejandro Colomar via Gcc]

[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/


OpenPGP_signature
Description: OpenPGP digital signature

Re: [C2x] Disallow function attributes after function identifier

[Alejandro Colomar via Gcc]

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/


OpenPGP_signature
Description: OpenPGP digital signature

New "Diving into GCC internals" section in newbies guide

[David Malcolm via Gcc]

I've written a large new chunk of documentation for my GCC newbies
guide, called "Diving into GCC internals", which can be seen at:

https://gcc-newbies-guide.readthedocs.io/en/latest/diving-into-gcc-internals.html

Hope this is helpful; please let me know if you see any mistakes, or if
there's room for improvement

Dave

gcc-11-20220610 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20220610 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20220610/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 60c84707034f025de3c8821cc5d6f27ff59143b0

You'll find:

 gcc-11-20220610.tar.xz   Complete GCC

  SHA256=2b881eab5a7463633cf5b582d09a8b8ceea9ecd10f0899ddd220bf791806ee37
  SHA1=8401d1670a87795ac0bf074c93364a715fb4350b

Diffs from 11-20220603 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [C2x] Disallow function attributes after function identifier

[Jonathan Wakely via Gcc]

On Fri, 10 Jun 2022, 22:29 Alejandro Colomar via Gcc, 
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: New "Diving into GCC internals" section in newbies guide

[Eric Botcazou via Gcc]

> Hope this is helpful; please let me know if you see any mistakes, or if
> there's room for improvement

Nice work!  In the "inside cc1" chapter, I think that IR is usually meant for 
"Intermediate Representation" rather than "Internal Representation" in this 
context.

-- 
Eric Botcazou

Re: New "Diving into GCC internals" section in newbies guide

[Sam James via Gcc]

> On 10 Jun 2022, at 22:58, David Malcolm via Gcc  wrote:
> 
> I've written a large new chunk of documentation for my GCC newbies
> guide, called "Diving into GCC internals", which can be seen at:
> 
> https://gcc-newbies-guide.readthedocs.io/en/latest/diving-into-gcc-internals.html
> 
> Hope this is helpful; please let me know if you see any mistakes, or if
> there's room for improvement
> 

I didn't even realise the guide existed at all!

This looks really interesting, thanks!

> Dave
> 



signature.asc
Description: Message signed with OpenPGP