[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: clang vs gcc warning flags
From:       Konstantin Belousov <kostikbel () gmail ! com>
Date:       2021-01-06 23:19:02
Message-ID: X/ZFZqdxkc3W/LNN () kib ! kiev ! ua
[Download RAW message or body]

On Wed, Jan 06, 2021 at 01:37:53PM -0800, Ryan Libby wrote:
> On Wed, Jan 6, 2021 at 12:06 PM Konstantin Belousov <kostikbel@gmail.com> wrote:
> >
> > On Wed, Jan 06, 2021 at 11:53:13AM -0800, Ryan Libby wrote:
> > >  - Wnested-externs I just do not understand.  We have specified this
> > >    warning flag for some 25 years but to me it seems completely without
> > >    value.  I suggest we just delete it.
> > I suspect this warning is to flag style(9) violations.
> 
> Which aspect do you mean?  I don't see it mentioned explicitly, but I
> know some of style(9) is reading between the lines.
> 
> If it's that objects with external linkage should be declared in
> headers, I think that doesn't address most of the cases where extern is
> actually used in our .c files.
It is more of agreement to put declarations with external linkage at top
level, not neccessary in headers.  But yes, people usually get follow-ups
to the commits when something is declared in .c (or did got follow-ups until
recent times).

And I think this is a reasonable rule for uniformity.

I do not believe we have any instance of use of nested function definition
in base, and I do not see why would we need this extension.  For the same
reason, for not being needed, Apple' blocks did not survived (but did
damaged our ABI somewhat).

> 
> Maybe the answer should be different for contrib software (where we
> don't generally enforce style)?
Of course we cannot enforce style(9) on contrib, it is not applicable by
any means.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]