> On Mar 28, 2023, at 5:53 PM, Roland Illig wrote:
>
> Am 15.03.2023 um 16:40 schrieb Jason Thorpe:
>>
>>> On Mar 15, 2023, at 4:23 AM, Taylor R Campbell
>>> wrote:
>>>
>>> Proposal: Forbid extern declarations in .c files.
>>>
>>> extern declarations in .c files invite easily avoided
Am 15.03.2023 um 16:40 schrieb Jason Thorpe:
On Mar 15, 2023, at 4:23 AM, Taylor R Campbell
wrote:
Proposal: Forbid extern declarations in .c files.
extern declarations in .c files invite easily avoided bugs where the
definition and use have mismatched types, because the compiler doesn't
>>> extern struct netif_stats le_stats[];
>>> ...
>>> struct netif_stats le_stats[NLE_IFS];
>> [riastradh@ and I say to s/extern/static/ and add static to the
>> later declaration, if le_stats can be file-local]
> Thanks, using 'static' as a forward declaration just works.
I may be misreading
> > extern struct netif_stats le_stats[];
> >
> > static struct netif_dif le_ifs[] = {
> > /* dif_unitdif_nseldif_stats dif_private */
> > { 0, NLE0CONF, _stats[0], le0conf,},
> > };
> > #define NLE_IFS (sizeof(le_ifs) /
It should be easy to add this check to lint by adding a new message. There are
several recent commits that add a message to lint1/err.c.
Whoever wants to add this check, feel free to do so. For external code and a
few other files, the newly added message will need to be excluded by
Date:Thu, 16 Mar 2023 05:21:47 +1100
From:matthew green
Message-ID: <6173.1678904...@splode.eterna.com.au>
| doing this should never be more than a quick hack
| and not in the commited treed.
It probably also needs to exclude machine generated code, eg:
yacc
> Pretty simple. Any objections?
yes please. doing this should never be more than a quick hack
and not in the commited treed.
thanks.
.mrg.
On Wed, Mar 15, 2023 at 11:23:05 +, Taylor R Campbell wrote:
> Proposal: Forbid extern declarations in .c files.
>
> extern declarations in .c files invite easily avoided bugs where the
> definition and use have mismatched types, because the compiler doesn't
> have an opportunity to check
> [...] I wonder how we can resolve this case:
> extern struct netif_stats le_stats[];
>
> static struct netif_dif le_ifs[] = {
> /*dif_unitdif_nseldif_stats dif_private */
> { 0, NLE0CONF, _stats[0], le0conf,},
> };
> #define
> Date: Thu, 16 Mar 2023 01:58:48 +0900
> From: Izumi Tsutsui
>
> > Proposal: Forbid extern declarations in .c files.
> :
> > Pretty simple. Any objections?
>
> No objection, but I wonder how we can resolve this case:
>
>
> Proposal: Forbid extern declarations in .c files.
:
> Pretty simple. Any objections?
No objection, but I wonder how we can resolve this case:
https://nxr.netbsd.org/xref/src/sys/arch/hp300/stand/common/if_le.c?r=1.14#101
---
extern struct netif_stats le_stats[];
static struct
On Wed, Mar 15, 2023 at 11:23:05AM +, Taylor R Campbell wrote:
> Proposal: Forbid extern declarations in .c files.
>
> extern declarations in .c files invite easily avoided bugs where the
> definition and use have mismatched types, because the compiler doesn't
> have an opportunity to check
On Wed, 15 Mar 2023, Taylor R Campbell wrote:
Proposal: Forbid extern declarations in .c files.
extern declarations in .c files invite easily avoided bugs where the
definition and use have mismatched types, because the compiler doesn't
have an opportunity to check them. Fix: Always put the
> On Mar 15, 2023, at 4:23 AM, Taylor R Campbell
> wrote:
>
> Proposal: Forbid extern declarations in .c files.
>
> extern declarations in .c files invite easily avoided bugs where the
> definition and use have mismatched types, because the compiler doesn't
> have an opportunity to check
Proposal: Forbid extern declarations in .c files.
extern declarations in .c files invite easily avoided bugs where the
definition and use have mismatched types, because the compiler doesn't
have an opportunity to check them. Fix: Always put the extern
declaration in a .h file shared by the .c
15 matches
Mail list logo
