Menu
▾
▴
#5 including unistd.h triggers an Internal Bug with +posixlib
From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473595
$ cat a.c
#include <unistd.h>
int main()
{
return 0;
}
$
$ splint a.c +posixlib
Splint 3.1.2 --- 03 Feb 2008
/usr/include/bits/confname.h:31:27: *** Internal Bug at cscannerHelp.c:2428:
Unexpanded macro not function or constant: int _PC_MAX_CANON [errno: 25]
*** Please report bug to submit@bugs.debian.org (via reportbug) ***
(attempting to continue, results may be incorrect)
/usr/include/bits/confname.h:32:1: Parse Error: Non-function declaration:
_PC_MAX_CANON : int. (For help on parse errors, see splint -help
parseerrors.)
*** Cannot continue.
Logged In: YES
user_id=73891
Originator: YES
From /usr/include/bits/confname.h (glibc 2.7-9 on Debian)
21 #ifndef _UNISTD_H
22 # error "Never use <bits/confname.h> directly; include <unistd.h> instead."
23 #endif
24
25 /* Values for the NAME argument to `pathconf' and `fpathconf'. */
26 enum
27 {
28 _PC_LINK_MAX,
29 #define _PC_LINK_MAX _PC_LINK_MAX
30 _PC_MAX_CANON,
31 #define _PC_MAX_CANON _PC_MAX_CANON
32 _PC_MAX_INPUT,
33 #define _PC_MAX_INPUT _PC_MAX_INPUT
34 _PC_NAME_MAX,
35 #define _PC_NAME_MAX _PC_NAME_MAX
Possible workaround.
On 08/12/05 12:27 +0100, Christoph Thielecke said ...
> I find also a tip on:
> http://www.perlfoundation.org/parrot/index.cgi?action=display_html;page_name=splint
>
> ==>
> Recursive #define in a header file
> My /usr/include/bits/confname.h includes both enums and defines for the same
> tokens. It looks like this:
> enum
> {
> _PC_LINK_MAX,
> #define _PC_LINK_MAX _PC_LINK_MAX
> _PC_MAX_CANON,
> #define _PC_MAX_CANON _PC_MAX_CANON
> etc, etc. I'm guessing they want to use an enum for compile-time
> typechecking, but retain compatibility with code that uses #ifdef to
> determine its presence, or something. Anyway, splint barfs on this with
> an "internal error":
> /usr/include/bits/confname.h:31:27: *** Internal Bug at cscannerHelp.c:2422:
> Unexpanded macro not function or constant: int _PC_MAX_CANON [errno: 25]
> *** Please report bug to splint-bug@splint.org ***
> (attempting to continue, results may be incorrect)
> /usr/include/bits/confname.h:32:1: Parse Error: Non-function declaration:
> _PC_MAX_CANON : int. (For help on parse errors, see splint -help
> parseerrors.)
> *** Cannot continue.
>
>
> The nice thing about this error, of course, is that it waits until after all
> sourcefile processing to emit this error. Which means you think everything's
> running great, and yet you're denied your nifty summary at the end.
> For now, I've wrapped my system include with #ifndef S_SPLINT_S. But its
> another argument in favor of keeping splint as far away from system headers
> as possible...
> <===
I beleive this is a debian package problem. System headers are not suppose to be parsed by splint. Using the '+posixlib' will use annotated versions of this file. Possibly this has already been fixed in CVS? I can not reproduce.
The debian packag splint-data has the lcd, etc files. The current version in CVS has fixed this issue.
Still not fixed in CVS either. The options 'const-macros' or 'all-macros' change the way splint interprets macros. The problem is that splint does two scans of a file. The first replaces macros with an annotation to be scanned on the next pass. During this pass, the macro is added to a symbol table. On the 2nd pass, the macro is known on the enum parse and is 'replaced' before it is defined. There are many possible solutions, but the cscannerHelp_processIdentifier() function is rather complicated (possible to return NEW_IDENTIFIER) or possibly augment the' @QLMR' token handling to set an 'isSeen' value for symbols.
Sorry, this is fixed in CVS. I had altered the code to diagnose another problem and re-created the same issue that was in the previous release.
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
This does work for me, but several people have reported it as an issue, but no one is able to supply a simple test case and they do not supply options or configuration files.