[splint-discuss] splint and c99

Jake Holland JHolland at FASTSOFT.COM
Fri Jul 18 13:19:13 PDT 2008



I joined this mailing list a few weeks ago because I would like to
submit a patch.  



I sent mostly the same email then, but with the full (edited) cgrammar.y
attached instead of a patch, and I got a warning about how it went to
the moderator for being too big.  I never got anything after that, so I
thought I'd re-send something smaller.  My apologies if you end up
getting both messages.



I've attached a patch for a problem I was having with splint.  Would
anybody here be interested in reviewing and commenting?  And does anyone
have advice on how I should go about getting this behavior into the
official splint code base?


A description of my problem and solution follows.



One of the differences between C89 and C99 is illustrated with this
function definition:


int f() {

            int x = 0;


            int y = 0; /* 0 */


            return x+y;



I believe the line marked "/* 0 */" is illegal in C89, but legal in C99.
If I'm not mistaken, in C89, all variables declared inside a compound
statement must be declared at the top of the compound statement.  Once
you have a statement which is not a declaration or its initializer, you
can no longer declare more variables.


In C99, I think the grammar for compound statements in section 6.8.2
indicates this is no longer a restriction.


Splint version 3.1.2 (and, I believe, the latest dev version from cvs)
report "Parse Error" for this code, giving the line number of the marked



Our code base uses this feature of C99 in a number of places, and
splint's handling of this case was a barrier to adopting splint in our
build process.


So I downloaded the splint source and took a look at cgrammar.y, and
found a more or less reasonable way to allow it, I think without
introducing any other significant changes.  However, it's hard to be
sure, given my utter unfamiliarity with the code base.


This introduced 2 more shift/reduce conflicts (for a total now of 159,
instead of the expected 157), but otherwise completed the make
(including tests) without errors or warnings.  (I did my build on cygwin
under Windows Vista Home and Windows XP.)


With this change, running splint on a file with the above function
produced no errors.



The key differences are between lines 1871 and 1888.  I basically
introduced some rules so that in a compound statement, either stmtLists
could follow initializerLists, or vice versa.


My first attempt had what I thought was a cleaner solution, with a rule
allowing a stmt | initializer | stmt compoundRecurse | initializer
compoundRecurse.  However, this introduced extra reduce/reduce errors
and some errors about parsing macros, so I tried this change, which
seems not to conflict as heavily with other extensions.  If somebody
would prefer to help me pursue that approach to letting the change in
the way it is, I think I can reproduce those details.



Thanks in advance for any responses,



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080718/52cc25f6/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cgrammar.y.patch
Type: application/octet-stream
Size: 2294 bytes
Desc: cgrammar.y.patch
Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080718/52cc25f6/attachment.obj 

More information about the splint-discuss mailing list