From john.matthews at picochip.com Wed Jul 5 09:25:58 2006 From: john.matthews at picochip.com (John Matthews) Date: Wed Jul 5 09:25:55 2006 Subject: [splint-discuss] Option to allow gcc mixed code/declarations In-Reply-To: <1152105477.4135.51.camel@wey.picochip.com> References: <1152105477.4135.51.camel@wey.picochip.com> Message-ID: <1152105958.4135.54.camel@wey.picochip.com> Hi- I'm trying to use splint to check some existing code that has variable declarations within code ie. not just at the top of blocks, as allowed by gcc. Is there a way of persuading splint that this is ok, instead of stopping with a parse error? BTW +gnuextensions doesn't help. TIA John This email and any files transmitted with it are confidential and intended solely for the use of the individuals to whom they are addressed. If you have received this email in error please notify the sender and delete the message from your system immediately. From venkiah at ensea.fr Wed Jul 5 09:55:07 2006 From: venkiah at ensea.fr (Auguste Venkiah) Date: Wed Jul 5 09:55:21 2006 Subject: [splint-discuss] Option to allow gcc mixed code/declarations In-Reply-To: <1152105958.4135.54.camel@wey.picochip.com> References: <1152105477.4135.51.camel@wey.picochip.com> <1152105958.4135.54.camel@wey.picochip.com> Message-ID: <1152107709.16706.22.camel@mowgly.ensea.fr> The only way I got arround this is : #ifndef S_SPLINT_S /* Code to ignore be ignored by splint */ #endif Splint conforms to ISO C90 which does not allow intermixed code and declarations. All declarations have to be at the top of a block. That is to say : there is no way of 'telling' splint that your piece of code is OK because is not ISO C90; however, you can tell splint to ignore the corresponding line in order to avoid parse errors. Le mercredi 05 juillet 2006 ? 14:25 +0100, John Matthews a ?crit : > Hi- I'm trying to use splint to check some existing code that has > variable declarations within code ie. not just at the top of blocks, as > allowed by gcc. Is there a way of persuading splint that this is ok, > instead of stopping with a parse error? BTW +gnuextensions doesn't > help. > TIA > John > > This email and any files transmitted with it are confidential and intended solely for the use of the individuals to whom they are addressed. If you have received this email in error please notify the sender and delete the message from your system immediately. > _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss > From johnm at picochip.com Thu Jul 6 03:59:40 2006 From: johnm at picochip.com (John Matthews) Date: Thu Jul 6 03:59:40 2006 Subject: [splint-discuss] Option to allow gcc mixed code/declarations Message-ID: <001b01c6a0d2$226d69d0$0601a8c0@picochip.com> Thanks Auguste- I appreciate that the code isn't C90. But then neither are the other gcc extensions that +gnuextensions tells splint to ignore; why not this as well? Yes, I can modify the offending code, but there's quite a lot of it :-( John > The only way I got arround this is : > > #ifndef S_SPLINT_S > /* Code to ignore be ignored by splint */ > #endif > > Splint conforms to ISO C90 which does not allow intermixed code and > declarations. All declarations have to be at the top of a block. > > That is to say : there is no way of 'telling' splint that your piece of > code is OK because is not ISO C90; however, you can tell splint to > ignore the corresponding line in order to avoid parse errors. > > Le mercredi 05 juillet 2006 ? 14:25 +0100, John Matthews a ?crit : > > Hi- I'm trying to use splint to check some existing code that has > > variable declarations within code ie. not just at the top of blocks, as > > allowed by gcc. Is there a way of persuading splint that this is ok, > > instead of stopping with a parse error? BTW +gnuextensions doesn't > > help. > > TIA > > John This email and any files transmitted with it are confidential and intended solely for the use of the individuals to whom they are addressed. If you have received this email in error please notify the sender and delete the message from your system immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20060706/37e8eb05/attachment.htm From venkiah at ensea.fr Thu Jul 6 08:42:47 2006 From: venkiah at ensea.fr (Auguste Venkiah) Date: Thu Jul 6 08:42:55 2006 Subject: [splint-discuss] Option to allow gcc mixed code/declarations In-Reply-To: <001b01c6a0d2$226d69d0$0601a8c0@picochip.com> References: <001b01c6a0d2$226d69d0$0601a8c0@picochip.com> Message-ID: <1152189767.28450.14.camel@mowgly.ensea.fr> Le jeudi 06 juillet 2006 ? 08:59 +0100, John Matthews a ?crit : > Thanks Auguste- I appreciate that the code isn't C90. But then neither > are the other gcc extensions that +gnuextensions tells splint to > ignore; why not this as well? I guess that the +gnuextensions should have been a solution to this problem. However, I remember having seen this topic on the mailing list before. Clearly, this seems to be an issue to many people, but maintainers seem to have very little time. Noboby actually seems to be in the position to update the parser to support ISO C99. (sad, because splint is really a __great__ tool for writing good code and save debugging time ...) Moreover, I was also surprised that : /*@ignore@*/ ... /*@end@*/ did not do the trick. Only #ifndef S_SPLINT_S ... #endif worked, but perhaps this is just a misunderstanding of the /*@ignore@*/ mechanism. > > Yes, I can modify the offending code, but there's quite a lot of > it :-( #ifndef S_SPLINT_S ... #endif arround the offending code could still enable you to use splint for the rest of the code though. Hopefully, ISO C99 will be supported one day (?!) From Michael.Wojcik at MicroFocus.com Thu Jul 6 10:14:45 2006 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Thu Jul 6 10:16:16 2006 Subject: [splint-discuss] Option to allow gcc mixed code/declarations Message-ID: <11352F9641010A418AD5057945A3A6594CBE3F@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces@cs.virginia.edu > [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of > Auguste Venkiah > Sent: Thursday, 06 July, 2006 08:43 > > Le jeudi 06 juillet 2006 ? 08:59 +0100, John Matthews a ?crit : > > Thanks Auguste- I appreciate that the code isn't C90. But then neither > > are the other gcc extensions that +gnuextensions tells splint to > > ignore; why not this as well? > > I guess that the +gnuextensions should have been a solution to this > problem. However, I remember having seen this topic on the > mailing list before. > Clearly, this seems to be an issue to many people, but maintainers seem > to have very little time. Splint isn't actively maintained, according to discussions on the list at the end of last year. David Evans asked for volunteers (in a message dated 2005-12-18) but I don't believe anyone stepped up. > Noboby actually seems to be in the position to > update the parser to support ISO C99. Since C99-conformant implementations are rare and have little market share, C99 is hardly the best near-term goal for Splint updates. (GCC is not C99-conformant.) Adding support for declarations anywhere in a block, as part of +gnuextensions and/or another option, would make more sense. (It wouldn't be one of *my* priorities, because I dislike that "extension" and would much rather see various bugs in processing conforming C code fixed, but hey - it's open source, so people can fix whatever they like.) -- Michael Wojcik Principal Software Systems Developer, Micro Focus From lholzheid at bihl-wiedemann.de Mon Jul 10 16:09:16 2006 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Mon Jul 10 16:09:25 2006 Subject: [splint-discuss] (How) does the 'unsignedintegraltype' annotation work? In-Reply-To: <20060629135945.GA12619@svr5.bihl-wiedemann.de> References: <20060629135945.GA12619@svr5.bihl-wiedemann.de> Message-ID: <20060710200916.GA6502@svr5.bihl-wiedemann.de> On Thu, 2006-06-29 15:59:45 +0200, I wrote: > [..] > the 'unsignedintegraltype' annotation does not work as I expect: > [..] Splint didn't complain about the assignment of negative integer constants and integer constants without the 'u' suffix to variables with /*@unsignedintegraltype@*/ annotated type, because I was missing the -numliteral flag. However, with -numliteral, splint complains about _all_ assignments of constants to /*@unsignedintegraltype@*/ variables. The attached patch changes splint to the behavior I initially expected: uint8_t u8a; int8_t i8a; u8a = 1; // warning u8a = 1u; // no warning u8a = 1l; // warning u8a = 1lu; // no warning u8a = -1; // warning i8a = 1; // no warning i8a = 1u; // warning i8a = 1l; // no warning i8a = 1lu; // warning i8a = -1; // no warning Is the changed behavior reasonable? Could anyone review the patch (or be responsive in other way)? Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flo?w?rthstra?e 41 e-mail: lholzheid@bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- -------------- next part -------------- diff -ur --exclude '*.lcd' splint-3.1.1/lib/standard.h splint-3.1.1.modified/lib/standard.h --- splint-3.1.1/lib/standard.h 2003-04-21 00:45:10.000000000 +0200 +++ splint-3.1.1.modified/lib/standard.h 2006-07-09 21:08:52.000000000 +0200 @@ -1159,16 +1159,16 @@ ** These types are OPTIONAL. Provide warnings on use. */ -typedef /*@integraltype@*/ int8_t +typedef /*@signedintegraltype@*/ int8_t /*@warn implementationoptional "ISO99 specifies as optional type, implementation need not provide. Consider int_least8_t instead."@*/ ; -typedef /*@integraltype@*/ int16_t +typedef /*@signedintegraltype@*/ int16_t /*@warn implementationoptional "ISO99 specifies as optional type, implementation need not provide. Consider int_least16_t instead."@*/ ; -typedef /*@integraltype@*/ int32_t +typedef /*@signedintegraltype@*/ int32_t /*@warn implementationoptional "ISO99 specifies as optional type, implementation need not provide. Consider int_least32_t instead."@*/ ; -typedef /*@integraltype@*/ int64_t +typedef /*@signedintegraltype@*/ int64_t /*@warn implementationoptional "ISO99 specifies as optional type, implementation need not provide. Consider int_least64_t instead."@*/ ; typedef /*@unsignedintegraltype@*/ uint8_t @@ -1183,20 +1183,20 @@ typedef /*@unsignedintegraltype@*/ uint64_t /*@warn implementationoptional "ISO99 specifies as optional type, implementation need not provide. Consider uint_least64_t instead."@*/ ; -typedef /*@integraltype@*/ int_least8_t; -typedef /*@integraltype@*/ int_least16_t; -typedef /*@integraltype@*/ int_least32_t; -typedef /*@integraltype@*/ int_least64_t; +typedef /*@signedintegraltype@*/ int_least8_t; +typedef /*@signedintegraltype@*/ int_least16_t; +typedef /*@signedintegraltype@*/ int_least32_t; +typedef /*@signedintegraltype@*/ int_least64_t; typedef /*@unsignedintegraltype@*/ uint_least8_t; typedef /*@unsignedintegraltype@*/ uint_least16_t; typedef /*@unsignedintegraltype@*/ uint_least32_t; typedef /*@unsignedintegraltype@*/ uint_least64_t; -typedef /*@integraltype@*/ int_fast8_t; -typedef /*@integraltype@*/ int_fast16_t; -typedef /*@integraltype@*/ int_fast32_t; -typedef /*@integraltype@*/ int_fast64_t; +typedef /*@signedintegraltype@*/ int_fast8_t; +typedef /*@signedintegraltype@*/ int_fast16_t; +typedef /*@signedintegraltype@*/ int_fast32_t; +typedef /*@signedintegraltype@*/ int_fast64_t; typedef /*@unsignedintegraltype@*/ uint_fast8_t; typedef /*@unsignedintegraltype@*/ uint_fast16_t; diff -ur --exclude '*.lcd' splint-3.1.1/src/cprim.c splint-3.1.1.modified/src/cprim.c --- splint-3.1.1/src/cprim.c 2003-03-02 20:59:12.000000000 +0100 +++ splint-3.1.1.modified/src/cprim.c 2006-07-09 21:15:12.000000000 +0200 @@ -126,9 +126,15 @@ { return (cprim_closeEnough (CTX_ULINT, c2)); } + else if (context_getFlag (FLG_IGNORESIGNS)) + { + return (cprim_isAnyInt (c2) + || (cprim_isAnyChar (c2) && context_msgCharInt ())); + } else { - return FALSE; + return (cprim_isAnyUnsignedInt (c2) + || (cprim_isUnsignedChar (c2) && context_msgCharInt ())); } } @@ -144,9 +150,15 @@ { return (cprim_closeEnough (CTX_LINT, c2)); } + else if (context_getFlag (FLG_IGNORESIGNS)) + { + return (cprim_isAnyInt (c2) + || (cprim_isAnyChar (c2) && context_msgCharInt ())); + } else { - return FALSE; + return (cprim_isAnySignedInt (c2) + || (cprim_isSignedChar (c2) && context_msgCharInt ())); } } @@ -182,9 +194,15 @@ { return (cprim_closeEnough (c1, CTX_ULINT)); } + else if (context_getFlag (FLG_IGNORESIGNS)) + { + return (cprim_isAnyInt (c1) + || (cprim_isAnyChar (c1) && context_msgCharInt ())); + } else { - return FALSE; + return (cprim_isAnyUnsignedInt (c1) + || (cprim_isUnsignedChar (c1) && context_msgCharInt ())); } } @@ -199,9 +217,15 @@ { return (cprim_closeEnough (c1, CTX_LINT)); } + else if (context_getFlag (FLG_IGNORESIGNS)) + { + return (cprim_isAnyInt (c1) + || (cprim_isAnyChar (c1) && context_msgCharInt ())); + } else { - return FALSE; + return (cprim_isAnySignedInt (c1) + || (cprim_isSignedChar (c1) && context_msgCharInt ())); } } diff -ur --exclude '*.lcd' splint-3.1.1/src/Headers/cprim.h splint-3.1.1.modified/src/Headers/cprim.h --- splint-3.1.1/src/Headers/cprim.h 2003-03-02 21:18:44.000000000 +0100 +++ splint-3.1.1.modified/src/Headers/cprim.h 2006-07-09 18:41:36.000000000 +0200 @@ -99,6 +99,12 @@ # define cprim_isAnyUnsignedInt(c) ((c) == CTX_UINT || (c) == CTX_USINT \ || (c) == CTX_ULINT || (c) == CTX_ULLINT \ || (c) == CTX_UNSIGNEDINTEGRAL) + +extern bool cprim_isAnySignedInt (/*@sef@*/ cprim p_c); +# define cprim_isAnySignedInt(c) ((c) == CTX_INT || (c) == CTX_SINT \ + || (c) == CTX_LINT || (c) == CTX_LLINT \ + || (c) == CTX_SIGNEDINTEGRAL) + # define cprim_isAnyReal(c) ((c) >= CTX_FLOAT && (c) <= CTX_LDOUBLE) /*@constant int CTX_LAST;@*/ From aabelka at gmail.com Thu Jul 20 07:41:19 2006 From: aabelka at gmail.com (ABDESSELEM Belkacem) Date: Thu Jul 20 07:41:24 2006 Subject: [splint-discuss] information demand Message-ID: <8586aeb00607200441h18960175hc1b2bb0dd4d3a9e8@mail.gmail.com> Good morning, I want to know if we have a special porting to 64-bit flag in splint like -errchk=longprt64, signext option if lint tool regards. ^_^ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20060720/16a611cf/attachment.htm From lholzheid at bihl-wiedemann.de Thu Jul 20 14:58:13 2006 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Thu Jul 20 14:58:20 2006 Subject: [splint-discuss] information demand In-Reply-To: <8586aeb00607200441h18960175hc1b2bb0dd4d3a9e8@mail.gmail.com> References: <8586aeb00607200441h18960175hc1b2bb0dd4d3a9e8@mail.gmail.com> Message-ID: <20060720185813.GA7605@svr5.bihl-wiedemann.de> On Thu, 2006-07-20 13:41:19 +0200, ABDESSELEM Belkacem wrote: > I want to know if we have a special porting to 64-bit flag in splint like > -errchk=longprt64, signext option if lint tool I suppose the splint equivalence of the lint flag 'signext' is '-ignore-signs' (on by default). As far as I understood 'longptr64', it makes lint to complain about something like: int integer; void *pointer = NULL; integer = (int) pointer; Without the cast, splint would warn as long as the '-type' flag is not set. However, splint seems to assume that the programmers know what they are doing when casting explicitly ... Ludolf From kumar.amit at bhartitelesoft.com Thu Jul 20 23:36:26 2006 From: kumar.amit at bhartitelesoft.com (amit kumar) Date: Thu Jul 20 23:36:39 2006 Subject: [splint-discuss] Query Message-ID: <003601c6ac76$d8c47570$2b0310ac@bhartitelesoft.com> Hi all, The question is can we apply splint to our makefiles ie can i compile whole directory structure at once ............ Thanks in Advance Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20060721/e0e111c7/attachment.htm From ai2097 at yahoo.com Fri Jul 21 00:19:53 2006 From: ai2097 at yahoo.com (Quandary) Date: Fri Jul 21 00:20:03 2006 Subject: [splint-discuss] Query In-Reply-To: <003601c6ac76$d8c47570$2b0310ac@bhartitelesoft.com> Message-ID: <20060721041953.71027.qmail@web51714.mail.yahoo.com> Amit, Yes. As far as your build system is concerned, Splint is just a compiler. The only difference between Splint and a real compiler is that Splint yells at you instead of generating code ;). You may have to hack around some splint bugs in order to get things working all right, but this can usually be handled by telling your build system to pass Splint some extra flags. - Q --- amit kumar wrote: > Hi all, > The question is can we apply splint to our makefiles > ie can i compile whole directory structure at once ............ > > Thanks in Advance > Amit> _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From roland.illig at gmx.de Fri Jul 21 02:21:25 2006 From: roland.illig at gmx.de (Roland Illig) Date: Fri Jul 21 02:21:37 2006 Subject: [splint-discuss] Query In-Reply-To: <003601c6ac76$d8c47570$2b0310ac@bhartitelesoft.com> References: <003601c6ac76$d8c47570$2b0310ac@bhartitelesoft.com> Message-ID: <44C07265.5000502@gmx.de> amit kumar wrote: > Hi all, > The question is can we apply splint to our makefiles > ie can i compile whole directory structure at once ............ Yes, that should be possible. You may try the attached wrapper program. If it proves useful, maybe it can be included in the next SPlint release? Roland -------------- next part -------------- #! /usr/bin/env perl # # A wrapper for gcc that calls splint with the appropriate -D..., -I... # and -U... flags, and after that calls gcc. To use it, define the # Makefile variable CC="splintcc cc". # # Copyright (c) 2006 Roland Illig . # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # # This software is provided ``as is'' and without any warranties. # Use it at your own risk. # use strict; use warnings; use constant false => 0; use constant true => 1; my @lint_args = ("splint"); my @cc_args = (shift()); my $compiling = false; my $arg; while (defined($arg = shift(@ARGV))) { push(@cc_args, $arg); if ($arg =~ qr"^-[DIU]") { push(@lint_args, $arg); } elsif ($arg =~ qr"^(?:-E|-f.*|-m.*|-O.*|-S|-static|-W.*)$") { # ignore them for splint } elsif ($arg eq "-c") { push(@lint_args, "+partial"); $compiling = true; } elsif ($arg eq "-o") { # skip this and the next argument for splint push(@cc_args, shift(@ARGV)); } elsif ($arg =~ qr"^-.") { print STDERR "$0: warning: Unknown argument: $arg\n"; } else { push(@lint_args, $arg); } } # Only run SPlint when the "-c" option is given. if ($compiling) { system { $lint_args[0] } (@lint_args); } # Run the real compiler. exec { $cc_args[0] } (@cc_args) or die; From andreas.moroder at gmx.net Sun Jul 23 09:41:17 2006 From: andreas.moroder at gmx.net (Andreas Moroder) Date: Sun Jul 23 10:05:15 2006 Subject: [splint-discuss] Ignore errors in include files Message-ID: Hello, I try to debug a linux program that also includes gnome/glib include files. This includes file create many splint warnings. Is it posible to tell splint not to display and count the errors in files that are included with <> ? Bye Andreas From aabelka at gmail.com Mon Jul 24 04:10:24 2006 From: aabelka at gmail.com (ABDESSELEM Belkacem) Date: Mon Jul 24 04:10:29 2006 Subject: [splint-discuss] Ignore errors in include files In-Reply-To: References: Message-ID: <8586aeb00607240110ue36fb59t1c902ba1391edae5@mail.gmail.com> Hi, I think that -systemdirerrors option can be used to tell splint not to display and count the errors in files that are included with <>. kacem On 7/23/06, Andreas Moroder wrote: > > Hello, > > I try to debug a linux program that also includes gnome/glib include > files. > This includes file create many splint warnings. > > Is it posible to tell splint not to display and count the errors in files > that are included with <> ? > > Bye > Andreas > > > > _______________________________________________ > splint-discuss mailing list > splint-discuss@ares.cs.Virginia.EDU > http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss > -- B. Abdesselem -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20060724/c30261d6/attachment.htm From lholzheid at bihl-wiedemann.de Mon Jul 24 06:37:29 2006 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Mon Jul 24 06:37:37 2006 Subject: [splint-discuss] Ignore errors in include files In-Reply-To: References: Message-ID: <20060724103729.GA27209@svr5.bihl-wiedemann.de> On Sun, 2006-07-23 15:41:17 +0200, Andreas Moroder wrote: > [..] > Is it posible to tell splint not to display and count the errors in files > that are included with <> ? see +skip-sys-headers and -sys-dirs Ludolf From aabelka at gmail.com Tue Jul 25 05:23:49 2006 From: aabelka at gmail.com (ABDESSELEM Belkacem) Date: Tue Jul 25 05:23:57 2006 Subject: [splint-discuss] (no subject) Message-ID: <8586aeb00607250223y3ebd43a5n58c6fde2392a90e4@mail.gmail.com> I want to know what this message mean: "Type exported, but not specified:" Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20060725/5f11071e/attachment.htm