Hi Richard,
Thanks for your feedback. Let's take each issue one at a time.
0) Bison version
You're right, grammar was modified to use some features that aren't
present in older versions of Bison. This helps avoid ugly hacks that
were previously present in code in order to use multiple Bison
generated parsers in the same application. As I see it, now that make
dist works (and that means that the tarball includes all generated
files, including autotools ones or flex/bison ones), once the issue of
distributing tarballs is solved, a regular user should have no problem
(they wouldn't even need to have autotools, flex or bison installed);
the only ones constrained to have those tools (and use newer versions)
would be those that would want to hack the templates for those
generated files. Of course, this is theoretical, until there is a
tarball release - I'm still trying to figure out a way to host this
somewhere where I could also release tarballs (and maybe have some
decent bug-tracker).
1) Compiler warnings
I know of those warnings , I've inspected them and they're not
troublesome, though you're correct, it would be better if they were
addressed. I've tried to reduce compiler (and as a matter of fact even
linters, such as clang static analyzer, clang tidy, cppcheck,
sun/oracle lint) warnings (comparison with the upstream version shows
a decrease in the number of compiler warnings).
2) test failure for system header sys/types.h
At a glance, I don't understand what that test checks for, and
repository history doesn't help much. I might have a hunch about what
goes wrong there. But I want to tell you I don't have access to any
OSX machine, so I can't help, only give you some tips on how to
investigate what goes wrong.
First, something I did (my changes). You might know that C grammar has
an ambiguity problem, where
A * B;
might be interpreted as an multiplication expression or a declaration
of variable B of type A. This makes the grammar non LALR(1), requiring
special handling by LALR(1) generated parser (as is the Bison parser).
Basically, to do this, parser keeps a storage of all types and
identifiers it has seen, and on each identifier from scanner,
interrogates that storage to detect usage of previously declared type,
of a previously know identifier or it is a new identifier. Splint's C
grammar is no different, did this correctly. Yet, sometimes during
development, it was decided that in order to support some undeclared
system reserved symbols (those starting with __) that might be either
types or identifiers, the mechanism for discriminating between types
and identifiers should be crippled. This crippling exploded the number
of reduce/reduce conflicts. I've decided this has to stop, removing
the crippling that allowed unknown (system reserved) identifiers to be
parsed -- the correct solution seem to have such symbols properly
defined (either at compile or run time). So this might be the reason
why you might see failures where previously there weren't -- Splint
previously used to treat those specially, and sometimes not in the
correct way, but allowed parsing of unknown identifiers of a special
form. What I can say to support my decision is that previously
Splint's C grammar had 123 reduce/reduce conflicts, while now it has
17 (mainly due to macro & error handling) while also supporting more
syntax (as variable declaration inside for initialization) and
hopefully with less bugs.
This might explain why you're seeing a parse error. The problem might
be surprising for you because you assume some definition is already
read from a previously included header. I suspect the problem is
caused by the fact that header isn't actually included. Splint has a
somewhat surprisingly behaviour, meaning that by default, unless is a
blocker (as in a parsing error), all errors in system headers are
ignored and not reported, thus you might not see any complaint about
failing to find/include a system header. This is what I suspect
happens. To test that indeed this is the problem, run
$(SPLINT) -nof -hints -booltype "bool" utype.c
(the equivalent of the test) and look for the parsing error. Assuming
that it still exists, now run
$(SPLINT) -nof -hints -booltype "bool" utype.c -keep
which does the same thing, but additionally instructs Splint to keep
temporary preprocessed files (the name of the file will be printed).
Now look into the temporary (preprocessed) file, and look for the
missing definition ("__int64_t" in this case). If it's not there,
either the file it declared it wasn't included (preprocessor line
comments should help you find if that file was indeed included), or
you've found (yet another) bug.
Now, if the file wasn't included, most likely it is in a folder that
Splint doesn't know of (and thus doesn't look into). Using -sysdirs
flag to change the default include path should be a temporary fix,
once you know your system's correct list of include paths, should
reconfigure/recompile Splint to make the solution permanent.
Alternatively, if the header containing the definition is included,
I'll need your assistance in tracking such a bug (as I said, no OSX).
3) the *_unlocked I/O functions.
This behaviour didn't change in comparison with the previous version.
The problem is that those missing functions are declared, but in the
UNIX library, not the POSIX one. Thus doing your check with +unixlib
should be a temporary fix. You're correct, this should be fixed. As I
said in the announcement, my next important target for these patches
would be to correct and expand standard (C99) and POSIX library
support. So this is work in progress -- but I logged your bug, it
will be fixed soon.
In relation to you making clean and then rebuilding the libraries but
still failing to see the changed behaviour, Splint doesn't read the
library from the build directory (unless instructed to do so using
LARCH_PATH), by default it reads from its installation directory. Thus,
if you make further changes to the library that you want to test,
either change LARCH_PATH environment variable to the path used for
building, or actually install the new libraries
(make -C lib/ install)
4) (void)0 & -noeffect
I don't understand what doesn't work. Please provide a small sample
for me.
Regards,
Mihail.
_______________________________________________
splint-discuss mailing list
splint-discuss@mail.cs.virginia.edu
http://www.cs.virginia.edu/mailman/listinfo/splint-discuss
