NetBSD Problem Report #22500

Received: (qmail 10340 invoked by uid 605); 16 Aug 2003 00:18:04 -0000
Message-Id: <20030816001803.10331.qmail@mail.netbsd.org>
Date: 16 Aug 2003 00:18:03 -0000
From: kristerw@netbsd.org
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: kristerw@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: lint breakage for named initializers
X-Send-Pr-Version: 3.95

>Number:         22500
>Category:       toolchain
>Synopsis:       lint breakage for named initializers
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Aug 16 00:19:00 +0000 2003
>Closed-Date:    Mon Feb 07 04:12:09 +0000 2022
>Last-Modified:  Mon Feb 07 04:12:09 +0000 2022
>Originator:     Krister Walfridsson
>Release:        NetBSD-current as of 2003-08-15
>Organization:

>Environment:


System: NetBSD homeworld.netbsd.org 1.6.1 NetBSD 1.6.1 (HOMEWORLD) #2: Fri Jul 25 09:05:09 CDT 2003 root@aurora.ait.iastate.edu:/usr/NetBSD/kernels/compile/HOMEWORLD i386
Architecture: i386
Machine: i386
>Description:
It is not possible to lint an i386 GENERIC kernel, because lint barfs on
some usages of structure and union named initializers (for example in
dev/ic/icp_ioctl.c).

>How-To-Repeat:
# i386--netbsdelf-lint -S 1.c
1.c(9): undefined struct/union member: a [101]
# i386--netbsdelf-lint -S 2.c
2.c(9): lint error: /usr/local/tmp/nbsd030815/src/tools/lint1/../../usr.bin/xlint/lint1/init.c, 165: popi2()

for the files

--- /dev/null   Fri Aug 15 23:24:11 2003
+++ 1.c Sat Aug 16 02:12:50 2003
@@ -0,0 +1,9 @@
+struct {
+       union {
+               struct {
+                       int a1;
+                       int a2;
+               } a;
+               int b;
+       } c;
+} foo = {{.a = {0, 0}}};

--- /dev/null   Fri Aug 15 23:24:11 2003
+++ 2.c Sat Aug 16 01:54:24 2003
@@ -0,0 +1,9 @@
+struct {
+       union {
+               int a;
+               struct {
+                       int b1;
+                       int b2;
+               } b;
+       } c;
+} bar = {{.b = {0, 0}}};


>Fix:

>Release-Note:
>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/22500: lint breakage for named initializers
Date: Sun, 30 Mar 2008 18:44:52 +0000

 Not only is this not fixed, it gets even more exciting:

    --- 3.c ---
 struct {
 	struct {
 		int b;
 	} b;
 	struct {
 		int d;
 	} d;
 } bar = {{.b = .d = {0}}};
    --- end ---

 % lint -S 3.c
 3.c:
 lint: /usr/libexec/lint1 got SIGSEGV

 This isn't even syntactically valid; it shouldn't get as far as the
 initializer-handling code, but it does and that's where it dumps
 core.

 I took a look at the initializer-handling code, and it's quite
 resistant to any sort of quick inspection. Maybe it'll make sense if
 really dug through. Maybe I should do that sometime and rework it for
 clarity...

 -- 
 David A. Holland
 dholland@netbsd.org

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/22500: lint breakage for named initializers
Date: Sun, 31 Jul 2016 22:35:23 +0000

 On Sun, Mar 30, 2008 at 06:45:02PM +0000, David Holland wrote:
  >     --- 3.c ---
  >  struct {
  >  	struct {
  >  		int b;
  >  	} b;
  >  	struct {
  >  		int d;
  >  	} d;
  >  } bar = {{.b = .d = {0}}};
  >     --- end ---
  >  
  >  % lint -S 3.c
  >  3.c:
  >  lint: /usr/libexec/lint1 got SIGSEGV

 This is actually two problems, of which the first no longer crashes
 but instead gives an internal error:

    --- 4.c ---
 struct {
    int a;
 } b = {.a = {1}};
    --- end ---
 % lint -S 4.c
 (6): lint error:
 /usr/src/usr.bin/xlint/lint1/init.c, 170: popi2()

 and

    --- 5.c ---
 struct {
    int a;
 } b = {.c = 3};
    --- end ---
 % lint -S 5.c
 5.c:
 lint: /usr/libexec/lint1 got SIGSEGV

 The problem in case 4 is too many braces; it should not accept the
 {1}, or having done so it should fail to match the .a, or something;
 anyway the problem seems to be that closing off the second set of
 braces causes it to want to pop something off that isn't there.

 The problem in case 5 is that .c doesn't exist and nothing checks that
 it failed to look up (I guess), so the object has no type and then it
 crashes. The crash happens at line 297 of init.c:
    switch (istk->i_type->t_tspec)

 A third problem is that the grammar in cgram.y permits {.a = .b = 3}
 which it shouldn't. This I can fix.

 -- 
 David A. Holland
 dholland@netbsd.org

From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/22500 CVS commit: src/usr.bin/xlint/lint1
Date: Sun, 31 Jul 2016 22:38:04 +0000

 Module Name:	src
 Committed By:	dholland
 Date:		Sun Jul 31 22:38:04 UTC 2016

 Modified Files:
 	src/usr.bin/xlint/lint1: cgram.y

 Log Message:
 Don't allow initializers of the form { .a = .b = expr } as this is not
 valid. Helps a bit with PR 22500.


 To generate a diff of this commit:
 cvs rdiff -u -r1.78 -r1.79 src/usr.bin/xlint/lint1/cgram.y

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: rillig@NetBSD.org
State-Changed-When: Mon, 07 Feb 2022 04:12:09 +0000
State-Changed-Why:
The problems from 1.c and 2.c were fixed in init.c 1.26 from 2014-11-20.

The problem from 3.c was improved from a segmentation fault to an
internal error in init.c 1.27 from 2015-07-28.  It was further improved
to report a syntax error in cgram.y 1.79 from 2016-07-31.

The problems from 4.c and 5.c were fixed for NetBSD 10 in init.c 1.179 
from 2021-03-30.

Thanks for the PR.


>Unformatted:

Home	PR Database Search