lclint-interest message 114

From Fri Oct 18 11:30:33 1996
Subject: Hi and problem
From: Lars Balker Rasmussen 
Date: 18 Oct 1996 12:36:25 +0200
In-Reply-To: Mike Ellis's message of Wed, 16 Oct 1996 13:31:46 +0100
Lines: 58
X-Mailer: Red Gnus v0.52/Emacs 19.33
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit


I've been on this list for a couple of months now, but I haven't had the
time to experiment with LCLint until now, so I postponed my introductory

I'm a computer science student who's taken a year off for working as a
software engineer on a large scale C project.  My interest in LCLint is
due to the possible productivity gains in finding nasty bugs at a
pre-test state, which is also the reason our entire project is expected
to compile clean with `gcc -Wall -ansi -pedantic -Werror'.

I'm currently seeing how big an impact LCLint will have on our
coding-style.  Warnings are nice (well, you know what I mean :) ), but
excessively arcane constructs to prevent warnings are not.

Which leads me to my question:

The following C-file gives LCLint (2.2a) problems:


    typedef void (*f_t)(void);

    f_t f[] = {

I believe ending an array with a NULL element is a common idiom, but
this gives the error:

foo.c:4,5: Global funcs[0] initialized to null value: funcs[0] = NULL
  A reference with no null annotation is assigned or initialized to NULL.  Use
  /*@null@*/ to declare the reference as a possibly null pointer. (-nullassign
  will suppress message)

Hmm, so I'm expected to /*@null@*/ something in the declaration of f[].
I've tried putting it in between literally all the tokens in the above
programs, and either it has no effect, or I get (understandable) parse
errors...  A quick perusal of the manual didn't give me anything much to
go after either.

I did find a solution:

    typedef void (*f_t)(void);

    /*@null@*/ static f_t null_func = NULL;

    f_t f[] = {

But now we're back with the arcane constructs;  my boss vetoed that one ;-)

Is there any other way around this problem?
Lars Balker Rasmussen, Mjolner Informatics ApS

Previous Message Next Message Archive Summary LCLint Home Page David Evans
University of Virginia, Computer Science