RE: [splint-discuss] newbie question: search path for source tree
Just like the standard compiler, -I tells the exact root of the directory to add to the list. If you have includes in ./include, you need to do -I./include. Split will not search all subdirs for your include files, it will search its built-in paths and any -I you specify, but it won't work recursively. -Kyle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Imhoff, Luke Sent: Monday, July 26, 2004 12:44 PM To: [EMAIL PROTECTED] Subject: [splint-discuss] newbie question: search path for source tree Ok, this is probably just me being stupid for trying to get splint to work on Win2k thru cygwin, but I can't get splint to scan my source tree for includes. I'm trying to run: splint +checks +posixlib -I. device/*.c device/*.h diag/*.c diag/*.h drivers/*.c drivers/*.h lib/*.c lib/*.h my cwd is the src/application directory of my source tree (one level below the root) all the includes in the device c files should be under src/application so I thought -I. would search the current directory and it's children for the includes in the device c files, but splint keeps saying it can't find them on the search path. Do I need to expand '.' to the full path? -Luke Imhoff ___ splint-discuss mailing list [EMAIL PROTECTED] http://www.splint.org/mailman/listinfo/splint-discuss --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.726 / Virus Database: 481 - Release Date: 7/22/2004 ___ splint-discuss mailing list [EMAIL PROTECTED] http://www.splint.org/mailman/listinfo/splint-discuss
Re: [splint-discuss] newbie question: parse error
Hi Roland, I have 2 questions. $ ../../../bin/splint +posixlib -posix-lib -I/usr/include/glib-2.0 -I/usr/include/gtk-2.0 -I../plugins/ -I/usr/include/pango-1.0/ -I/usr/include/wine/wine *.c Splint 3.1.1 --- 26 Sep 2003 /usr/include/arpa/inet.h:35:27: Parse Error. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. I know that error. The offending line (Linux 2.4.21, Debian) is: typedef __socklen_t socklen_t; Splint does not recognize arpa/inet.h as a system header, but knows netinet/in.h. The type __socklen_t is defined in netinet/in.h. Splint does not parse this header and uses its own definitions instead. Therefore the identifier __socklen_t is not known to splint. Solution 1: Splint should have an additional library (like posixlib) that knows the Single Unix Specification (susv3). How do I include posixlib with Splint ? At present I am using two command line options: 1) +posixlib (as told in http://splint.org/manual/manual.html ) 2) -posix-lib ( given in man page for splint) I do not understand difference between the two options :( Solution 2: Write your own splint-specific header arpa/inet.h. #ifdef S_SPLINT_S # include splint-include/arpa/inet.h #else # include arpa/inet.h #endif splint-include/arpa/inet.h typedef /[EMAIL PROTECTED]@*/ socklen_t; /* ... other definitions ... */ EOF This seemed to work but I just want to make sure I am doing it the right way. I have put #ifdef .. #endif statements in test code that uses inet.h and created a replica of inet.h in splint-include folder and added the line typedef /[EMAIL PROTECTED]@*/ socklen_t; Thanks, nayan -- __ Get your free email from www.bolt.com! Powered by Outblaze ___ splint-discuss mailing list [EMAIL PROTECTED] http://www.splint.org/mailman/listinfo/splint-discuss
Re: [splint-discuss] newbie question: parse error
On Sat, Sep 27, 2003 at 03:57:41AM +0800, Nayan wrote: Hi, I am trying to run splint on GAIM code on Redhat 8 machine. I get parse error as shown below. inet.h is included from file internal.h. I have tried options given in help but they do not solve the probblem. Please help!! $ ../../../bin/splint +posixlib -posix-lib -I/usr/include/glib-2.0 -I/usr/include/gtk-2.0 -I../plugins/ -I/usr/include/pango-1.0/ -I/usr/include/wine/wine *.c Splint 3.1.1 --- 26 Sep 2003 /usr/include/arpa/inet.h:35:27: Parse Error. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. I know that error. The offending line (Linux 2.4.21, Debian) is: typedef __socklen_t socklen_t; Splint does not recognize arpa/inet.h as a system header, but knows netinet/in.h. The type __socklen_t is defined in netinet/in.h. Splint does not parse this header and uses its own definitions instead. Therefore the identifier __socklen_t is not known to splint. Solution 1: Splint should have an additional library (like posixlib) that knows the Single Unix Specification (susv3). Solution 2: Write your own splint-specific header arpa/inet.h. #ifdef S_SPLINT_S # include splint-include/arpa/inet.h #else # include arpa/inet.h #endif splint-include/arpa/inet.h typedef /[EMAIL PROTECTED]@*/ socklen_t; /* ... other definitions ... */ EOF Roland ___ splint-discuss mailing list [EMAIL PROTECTED] http://www.splint.org/mailman/listinfo/splint-discuss
Re: [splint-discuss] Newbie question
On Tue, Jul 29, 2003 at 12:16:52AM +0100, Kenny Stuart wrote:
Hi all,
Well I'm new to Splint and to this list, I've read the user guide and had a
quick browse through the archive but can't work out what I'm doing wrong,
please help.
%% Given the following example code:
#include stddef.h
/[EMAIL PROTECTED]@*/
struct Tomato { int a, b, c; };
typedef /[EMAIL PROTECTED]@*/ /[EMAIL PROTECTED]@*/ struct Tomato* TOMATO;
static TOMATO Tomato_create( void )
{
TOMATO tomato= (TOMATO)malloc( sizeof *tomato );
if( tomato != NULL ) {
tomato-a= tomato-b= tomato-c= 0;
}
tomato-a = 0;
tomato-b = 0;
tomato-c = 0;
return tomato;
}
%% and I run Splint thus:
splint +checks test.c
Splint 3.1.1 --- 12 April 2003
test.c: (in function Tomato_create)
test.c(43,10): Returned storage *tomato contains 3 undefined fields: a, b, c
Storage derivable from a parameter, return value or global is not defined.
Use /[EMAIL PROTECTED]@*/ to denote passed or returned storage which need not be
defined.
(Use -compdef to inhibit warning)
Finished checking --- 1 code warning
%% why am I getting the above warning?
%% the user guide would appear to indicate that this should not be so!
The following sentence is verbatim from Pg.25 [section 5.1 para.3] of the
Splint user guide:
For example, if p is a pointer to a structure, p is completely defined if
the value of p is NULL, or if every Field of the structure p points to is
completely defined.
The fields are completely defined when they are assigned a value.
The other error message is:
spl.c:10:10: Name tomato is reserved for future library extensions. Functions
beginning with is or to and a lowercase letter may be added to
ctype.h. (ISO99:7.26.2)
Internal name is reserved for system in ISO C99 standard (this should not be
necessary unless you are worried about C library implementations that violate
the standard and use macros). (Use either -isoreservedinternal or -namechecks
to inhibit warning)
Roland
___
splint-discuss mailing list
[EMAIL PROTECTED]
http://www.splint.org/mailman/listinfo/splint-discuss
Re: [splint-discuss] Newbie question
* Roland Illig wrote on Thu, Jul 31, 2003 at 01:05:43PM CEST:
On Tue, Jul 29, 2003 at 12:16:52AM +0100, Kenny Stuart wrote:
#include stddef.h
/[EMAIL PROTECTED]@*/
struct Tomato { int a, b, c; };
typedef /[EMAIL PROTECTED]@*/ /[EMAIL PROTECTED]@*/ struct Tomato* TOMATO;
static TOMATO Tomato_create( void )
{
TOMATO tomato= (TOMATO)malloc( sizeof *tomato );
Two problems here: In C code, it is rather unfortunate to cast the
return value from malloc, as converting von 'void *' to any other
pointer type is valid without a cast (unlike C++). Moreover, the cast
usually hides compiler complaints when converting from (malloc being
implicitly declared as returning) int to a pointer type (which is a
bug!). Solution: #include stdlib.h above, and omit the cast here.
if( tomato != NULL ) {
tomato-a= tomato-b= tomato-c= 0;
}
tomato-a = 0;
tomato-b = 0;
tomato-c = 0;
Actually, these are potential NULL dereferences (assuming you meant them
to be after the closing brace.
The original problem is kind of a limitation of splint[1], easily
circumvented by explicitly returning NULL in case the malloc failed.
return tomato;
}
Regards,
Ralf
[1] actually, if memory serves me right, it used to be the case splint
(or lclint, as it was then) would recognize this correctly. Can anyone
confirm this?
___
splint-discuss mailing list
[EMAIL PROTECTED]
http://www.splint.org/mailman/listinfo/splint-discuss
RE: [subs] Re: [splint-discuss] Newbie question
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ralf
Wildenhues
Sent: 31 July 2003 12:49
To: [EMAIL PROTECTED]
Subject: [subs] Re: [splint-discuss] Newbie question
* Roland Illig wrote on Thu, Jul 31, 2003 at 01:05:43PM CEST:
On Tue, Jul 29, 2003 at 12:16:52AM +0100, Kenny Stuart wrote:
#include stddef.h
/[EMAIL PROTECTED]@*/
struct Tomato { int a, b, c; };
typedef /[EMAIL PROTECTED]@*/ /[EMAIL PROTECTED]@*/ struct Tomato* TOMATO;
static TOMATO Tomato_create( void )
{
TOMATO tomato= (TOMATO)malloc( sizeof *tomato );
Two problems here: In C code, it is rather unfortunate to cast the
return value from malloc, as converting von 'void *' to any other
pointer type is valid without a cast (unlike C++). Moreover, the cast
usually hides compiler complaints when converting from (malloc being
implicitly declared as returning) int to a pointer type (which is a
bug!). Solution: #include stdlib.h above, and omit the cast here.
%%
Wow, I've not used 'C' for about 10 years, just started using it to take a
look at splint and totally forgot about implicit declarations, thanks for
the nudge, I just purchased a copy of ISO 9899/1999 for reference and see
implicit declarations have thankfully been removed, I like the fact you
don't need to explicitly cast from a null pointer to some other pointer type
for the reason you've given.
I'm not sure I would class conversion of an int to a pointer type as a bug
since it is described in the C99 standard as implementation defined, the way
I read it, although potentially non-portable, used properly it is likely to
yield the desired effect since the C99 standard (sorry, I've just purchased
the standard so I'm looking everything up, it'll wear off eventually ;)
further states that the mapping functions for converting a pointer to an
integer and vice versa are intended to be consistent with the addressing
structure of the execution environment, as my example code shows however,
it's easy (pre C99 at least) to do it accidentally, I won't be explicitly
casting null pointers again :)
if( tomato != NULL ) {
tomato-a= tomato-b= tomato-c= 0;
}
tomato-a = 0;
tomato-b = 0;
tomato-c = 0;
Actually, these are potential NULL dereferences (assuming you meant them
to be after the closing brace.
%%
Ah, I see you've already mentioned that.
The original problem is kind of a limitation of splint[1], easily
circumvented by explicitly returning NULL in case the malloc failed.
%%
That's a surprise since it explicitly requires multiple return statements,
which as best practice suggests, I avoid wherever possible, huh, I was
convinced I'd lost my mind and was doing something fundamentally wrong!
Does anyone know if that's something that's likely to be addressed?
Thanks to all for the feedback, I've no doubt I'm going to be asking more
newbie questions as I progress so please bear with me ;)
Kenny.
___
splint-discuss mailing list
[EMAIL PROTECTED]
http://www.splint.org/mailman/listinfo/splint-discuss
Re: [splint-discuss] Newbie question
I use to use the following memory allocation scheme: #define NEW(t) ((t *)(malloc (sizeof (t Bad idea. As already noted, if you forgot to #include stdlib.h, the cast will prevent the warning message you would normally have got. It's also a bad idea because you have to keep mentioning the type over and over and over, and if the variable type changes, the code will break. Better idea: #define new(var) (var) = emalloc(sizeof *(var)) #define new_array(var, n) (var) = emalloc((n) * sizeof *(var)) where emalloc() is a function just like malloc() but which catches errors. Then t *var; new(var); new_array(var, n+1); t *var = NEW (t) /* GOOD */ x *var = NEW (t) /* BAD, compiler complains about */ x *var = malloc (sizeof t) does not catch this kind of errors which amongst other things is why var = malloc(sizeof *var) is better. ___ splint-discuss mailing list [EMAIL PROTECTED] http://www.splint.org/mailman/listinfo/splint-discuss
