> On 27/03/2017, at 11:40 AM, Mihail Groza <unlupdest...@gmail.com> wrote:
> 1) missing definition (__i386__/__x86_64__) in OSX
> In my opinion Splint works as expected,
The example I happened to provide includes a header without mentioning
POSIX on the command line. I encountered quite a few cases where my
code only included standard POSIX headers and DID mention +posixlib on
the command line and STILL ran into this problem.
This is probably due to splint having an out-of-date idea of just
which headers are in the POSIX standard.
I provided a tiny example quickly because it was going to take a long
time to find the original example.
I am trying very hard to write code that is portable.
That's why I keep the SUSv3 and SUSv4 open while coding,
compile with -std=89, -std=c99, and -std=c11 to make
sure nothing's broken, and why I want to run Splint.
I *am* trying to get at POSIX features...
> Alternatively, you could use a
> definition like
> #define NOOP() /*@-noeffect@*/ do { (void)0; } while (false)
> /*@=noeffect@*/
> to avoid repeated noeffect annotations.
There are static checkers for C that throw hissy fits when they
see a conditional expression that always has one value. It doesn't
do wonders for test coverage analysis either.
>
> I'm not going to check the standard, I trust your research. What I can
> say is that Splint's preprocessor was borrowed from GCC's preprocessor
> some long time ago (the copyright says last FSF change dates back to
> 1997) prior to C99 being adopted. I assume that the (GNU CPP)
> upstream version changed quite a bit in the mean time, while Splint's
> version diverted somewhat from that old version -- I believe some
> serious amount of work would be needed for updating it with a newer
> version that would support such new features you've found to be
> missing.
Ah. *THAT* is a much more serious problem than any one symptom of it.
All I can reasonably expect you to do is log it as a known issue.
> 4) bogus & incorrect variable redefinition warning
> You're correct, Splint has some limitations, and this is one of them.
> Yet one of it's strong points is that it allows very flexibly
> annotations, thus for your specific example, you could do something
> like
> struct Linked { struct Linked *x; };
> static struct Linked a;
> static struct Linked b;
> /*@-redef@*/
> static struct Linked a = {&b};
> static struct Linked b = {&a};
> /*@=redef@*/
> which relaxes the redefinition warning in a focused manner,
> but with
> side-effects (incompatible changes between the tentative and the
> actual definition will not be reported, so this has to be used with
> caution).
The side effects are the problem.
In order to allow legal C, splint must allow
int x;
int x = 1;
int a[];
int a[2];
In order to forbid illegal C, splint must not allow
int x = 1;
int x = 2;
int a[1];
int a[2];
Sadly, /*@-redef@*/ allows ALL of these.
This isn't an insuperable problem, because every C compiler I have
access to *will* catch reDEFINITIONs and inconsistent types.
It's actually rather surprising that splint catches
int y;
float y;
when -redef is in effect but doesn't catch
int a[1];
int a[2];
because in both cases there is a difference in (complete) type.
I suppose splint doesn't regard the size as part of the type.
> I'll mark it down as an issue (the advice text could be easily
> rephrased, yet discriminating between tentative and actual definitions
> is not so easy).
An actual definition has an = in it. A tentative one doesn't.
_______________________________________________
splint-discuss mailing list
splint-discuss@mail.cs.virginia.edu
http://www.cs.virginia.edu/mailman/listinfo/splint-discuss
