From derek at knosof.co.uk Fri Aug 1 04:50:22 2008 From: derek at knosof.co.uk (Derek M Jones) Date: Fri, 01 Aug 2008 12:50:22 +0100 Subject: [splint-discuss] Splint-3.1.2 bugs - Mudflap In-Reply-To: <11352F9641010A418AD5057945A3A6590118B7A0@MTV-EXCHANGE.microfocus.com> References: <11352F9641010A418AD5057945A3A6590118B7A0@MTV-EXCHANGE.microfocus.com> Message-ID: <4892F87E.7080206@knosof.co.uk> Michael, >>> - struct operation op; >>> + struct operation op = {0,0,0,0,0}; >> This adds extra runtime overhead, but clearly does not fix >> any real bug, unlike the other kinds of changes provided. > > It's also unnecessarily verbose, since: > > struct operation op = {0}; > > will initialize all members of op appropriately... Verbosity (redundancy) has its uses. In this case it provides the opportunity for tools to check whether the number of fields expected by the developer is the same as the number of fields that appear in the code. -- Derek M. Jones tel: +44 (0) 1252 520 667 Knowledge Software Ltd mailto:derek at knosof.co.uk Source code analysis http://www.knosof.co.uk From Michael.Wojcik at MicroFocus.com Fri Aug 1 06:35:26 2008 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Fri, 1 Aug 2008 06:35:26 -0700 Subject: [splint-discuss] Splint-3.1.2 bugs - Mudflap In-Reply-To: <4892F87E.7080206@knosof.co.uk> References: <11352F9641010A418AD5057945A3A6590118B7A0@MTV-EXCHANGE.microfocus.com> <4892F87E.7080206@knosof.co.uk> Message-ID: <11352F9641010A418AD5057945A3A6590118B7AB@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > Derek M Jones > Sent: Friday, 01 August, 2008 07:50 > > >>> - struct operation op; > >>> + struct operation op = {0,0,0,0,0}; > >> This adds extra runtime overhead, but clearly does not fix > any real > >> bug, unlike the other kinds of changes provided. > > > > It's also unnecessarily verbose, since: > > > > struct operation op = {0}; > > > > will initialize all members of op appropriately... > > Verbosity (redundancy) has its uses. In this case it > provides the opportunity for tools to check whether the > number of fields expected by the developer is the same as the > number of fields that appear in the code. Not in the general case. The initializer {0, 0} will correctly initialize any aggregate with two or more fields, and should not produce a diagnostic if the type has more than two fields. See ISO 9899:1999 6.7.8 #21: "If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration". Of course, an implementation (or any other tool) can produce any diagnostics it wants, but one in this case would lead to far too many false positives when run against typical well-written code. So it would have to be an option, and code would have to be written to cater to it; and that being the case, it could equally well be some kind of annotation. And to what end? Often aggregate data types are partly abstract for consumers, and the initializing code doesn't need to, and shouldn't, know how many fields the structure has. APIs that use aggregate types are often defined in terms of: - include header X - define struct Y - set Y.a and Y.b - call Z passing Y Such an API, if written sensibly, can tolerate changes to the structure in the implementation that are not reflected by source changes in the consumer, provided the consumer initializes the structure correctly. -- Michael Wojcik Principal Software Systems Developer, Micro Focus From derek at knosof.co.uk Fri Aug 1 07:33:02 2008 From: derek at knosof.co.uk (Derek M Jones) Date: Fri, 01 Aug 2008 15:33:02 +0100 Subject: [splint-discuss] Splint-3.1.2 bugs - Mudflap In-Reply-To: <11352F9641010A418AD5057945A3A6590118B7AB@MTV-EXCHANGE.microfocus.com> References: <11352F9641010A418AD5057945A3A6590118B7A0@MTV-EXCHANGE.microfocus.com> <4892F87E.7080206@knosof.co.uk> <11352F9641010A418AD5057945A3A6590118B7AB@MTV-EXCHANGE.microfocus.com> Message-ID: <48931E9E.602@knosof.co.uk> Michael, >>> will initialize all members of op appropriately... >> Verbosity (redundancy) has its uses. In this case it >> provides the opportunity for tools to check whether the >> number of fields expected by the developer is the same as the >> number of fields that appear in the code. > > Not in the general case. The initializer {0, 0} will correctly > initialize any aggregate with two or more fields, and should not produce > a diagnostic if the type has more than two fields. > > See ISO 9899:1999 6.7.8 #21: Full text here (plus commentary) http://c0x.coding-guidelines.com/6.7.8.html > Of course, an implementation (or any other tool) can produce any > diagnostics it wants, but one in this case would lead to far too many > false positives when run against typical well-written code. So it would > have to be an option, and code would have to be written to cater to it; > and that being the case, it could equally well be some kind of > annotation. False positives are a problem. However, redundancy is always useful in that it provides an alternative view of the developers intent. Inconsistency of intent is something that tools can zero in on. There are two cases: 1) when too many initializers are provided (yes a constraint error; but many compilers will happily 'recover' from it) and 2) when insufficient initializers are present. In both cases the developer may be unaware of changes to the number of fields in the struct, or have incorrect beliefs about the number of members. Of course, if an array is involved it may be impractical to initialise all of its elements. -- Derek M. Jones tel: +44 (0) 1252 520 667 Knowledge Software Ltd mailto:derek at knosof.co.uk Source code analysis http://www.knosof.co.uk From Michael.Wojcik at MicroFocus.com Fri Aug 1 09:09:16 2008 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Fri, 1 Aug 2008 09:09:16 -0700 Subject: [splint-discuss] Splint-3.1.2 bugs - Mudflap In-Reply-To: <48931E9E.602@knosof.co.uk> References: <11352F9641010A418AD5057945A3A6590118B7A0@MTV-EXCHANGE.microfocus.com> <4892F87E.7080206@knosof.co.uk><11352F9641010A418AD5057945A3A6590118B7AB@MTV-EXCHANGE.microfocus.com> <48931E9E.602@knosof.co.uk> Message-ID: <11352F9641010A418AD5057945A3A6590118B7AE@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > Derek M Jones > Sent: Friday, 01 August, 2008 10:33 > > ... redundancy is always > useful in that it provides an alternative view of the developers intent. Agreed... > Inconsistency of intent is something that tools can zero in on. ... and agreed. However: > In both cases the developer may be unaware of changes to the > number of fields in the struct, or have incorrect beliefs > about the number of members. In many cases the developer shouldn't have *any* belief about the number of fields in the structure, as in the example in my previous note. In such cases, a coding practice that requires such a belief produces unnecessary and counterproductive coupling and breaks abstraction. An API can extend an opaque structure by appending new fields, without requiring source code changes in consuming code. Thanks to the "common prefix" rule, an API can even extend such a structure without requiring object changes, if the structure is defined with a modicum of forethought (so the implementation can tell whether the new fields are present, for example by using a version indicator in the prefix). My preference for abstract types in C is to use pointers to incomplete structures in the API, and only complete them in the implementation, with all operations on them implemented through API functions. But structures with documented and undocumented fields are a popular compromise, and in my opinion better than requiring consumers to write to a single, fixed representation and know it completely. In short, the developer's intent should often be: "I don't know, or care, how many fields this structure has. I'm going to initialize the whole thing, and then I'm going to set some fields explicitly, and I'm going to let the API implementation worry about the rest." Much (no doubt most) existing C code makes far too little use of abstraction. I can't endorse a blanket style rule that eliminates even more of it. -- Michael Wojcik Principal Software Systems Developer, Micro Focus From derek at knosof.co.uk Fri Aug 1 09:32:22 2008 From: derek at knosof.co.uk (Derek M Jones) Date: Fri, 01 Aug 2008 17:32:22 +0100 Subject: [splint-discuss] Splint-3.1.2 bugs - Mudflap In-Reply-To: <11352F9641010A418AD5057945A3A6590118B7AE@MTV-EXCHANGE.microfocus.com> References: <11352F9641010A418AD5057945A3A6590118B7A0@MTV-EXCHANGE.microfocus.com> <4892F87E.7080206@knosof.co.uk><11352F9641010A418AD5057945A3A6590118B7AB@MTV-EXCHANGE.microfocus.com> <48931E9E.602@knosof.co.uk> <11352F9641010A418AD5057945A3A6590118B7AE@MTV-EXCHANGE.microfocus.com> Message-ID: <48933A96.4040702@knosof.co.uk> Michael, > Much (no doubt most) existing C code makes far too little use of > abstraction. I can't endorse a blanket style rule that eliminates even > more of it. We live in a multicultural world and to be of practical benefit guidelines need to adapt to what people do. Telling developers that their method of designing interfaces is wrong and guidelines to aid that design methodology are not going to be created and supported is very counter productive. -- Derek M. Jones tel: +44 (0) 1252 520 667 Knowledge Software Ltd mailto:derek at knosof.co.uk Source code analysis http://www.knosof.co.uk From toxygen1 at gmail.com Wed Aug 6 11:59:37 2008 From: toxygen1 at gmail.com (Marian Such) Date: Wed, 6 Aug 2008 20:59:37 +0200 Subject: [splint-discuss] Patch for splint to compile on mac os x Message-ID: <5E5607DA-0746-4A5C-BCDC-CB434BDA069C@gmail.com> Hello, here is patch to make splint compile without error on Mac OS X. # diff -u src/osd.c src/osd_new.c --- src/osd.c 2007-07-14 00:18:20.000000000 +0200 +++ src/osd_new.c 2008-08-06 20:41:21.000000000 +0200 @@ -515,6 +515,8 @@ { # if defined (WIN32) || defined (OS2) && defined (__IBMC__) int pid = _getpid (); +# elif __APPLE__ + __darwin_pid_t pid = getpid (); # else __pid_t pid = getpid (); # endif Regards Marian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080806/f48b34ab/attachment.html From toxygen1 at gmail.com Wed Aug 6 12:27:29 2008 From: toxygen1 at gmail.com (Marian Such) Date: Wed, 6 Aug 2008 21:27:29 +0200 Subject: [splint-discuss] Patch for splint to compile on mac os x In-Reply-To: <5E5607DA-0746-4A5C-BCDC-CB434BDA069C@gmail.com> References: <5E5607DA-0746-4A5C-BCDC-CB434BDA069C@gmail.com> Message-ID: <279327B9-764C-432D-8C92-46D97773BC3D@gmail.com> # diff -u src/osd.c src/osd_new.c --- src/osd.c 2007-07-14 00:18:20.000000000 +0200 +++ src/osd_new.c 2008-08-06 21:26:09.000000000 +0200 @@ -515,6 +515,8 @@ { # if defined (WIN32) || defined (OS2) && defined (__IBMC__) int pid = _getpid (); +# elif defined (__APPLE__) + __darwin_pid_t pid = getpid (); # else __pid_t pid = getpid (); # endif On Aug 6, 2008, at 8:59 PM, Marian Such wrote: I hurried a little bit. This is more nice and does the same job in nicer manner. Marian > Hello, > here is patch to make splint compile without error on Mac OS X. > > # diff -u src/osd.c src/osd_new.c > --- src/osd.c 2007-07-14 00:18:20.000000000 +0200 > +++ src/osd_new.c 2008-08-06 20:41:21.000000000 +0200 > @@ -515,6 +515,8 @@ > { > # if defined (WIN32) || defined (OS2) && defined (__IBMC__) > int pid = _getpid (); > +# elif __APPLE__ > + __darwin_pid_t pid = getpid (); > # else > __pid_t pid = getpid (); > # endif > > Regards > > Marian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080806/22452b53/attachment.html From roland.illig at gmx.de Wed Aug 6 14:16:20 2008 From: roland.illig at gmx.de (Roland Illig) Date: Wed, 06 Aug 2008 23:16:20 +0200 Subject: [splint-discuss] Patch for splint to compile on mac os x In-Reply-To: <279327B9-764C-432D-8C92-46D97773BC3D@gmail.com> References: <5E5607DA-0746-4A5C-BCDC-CB434BDA069C@gmail.com> <279327B9-764C-432D-8C92-46D97773BC3D@gmail.com> Message-ID: <489A14A4.1080208@gmx.de> Marian Such schrieb: > # diff -u src/osd.c src/osd_new.c > --- src/osd.c 2007-07-14 00:18:20.000000000 +0200 > +++ src/osd_new.c 2008-08-06 21:26:09.000000000 +0200 > @@ -515,6 +515,8 @@ > { > # if defined (WIN32) || defined (OS2) && defined (__IBMC__) > int pid = _getpid (); > +# elif defined (__APPLE__) > + __darwin_pid_t pid = getpid (); Why do you need __darwin_pid_t here? Shouldn't just pid_t suffice? Roland From toxygen1 at gmail.com Wed Aug 6 15:35:29 2008 From: toxygen1 at gmail.com (Marian Such) Date: Thu, 7 Aug 2008 00:35:29 +0200 Subject: [splint-discuss] Patch for splint to compile on mac os x In-Reply-To: <489A14A4.1080208@gmx.de> References: <5E5607DA-0746-4A5C-BCDC-CB434BDA069C@gmail.com> <279327B9-764C-432D-8C92-46D97773BC3D@gmail.com> <489A14A4.1080208@gmx.de> Message-ID: <9A42B97B-B028-4C2C-9FBD-364295158E2F@gmail.com> On Aug 6, 2008, at 11:16 PM, Roland Illig wrote: > Marian Such schrieb: >> # diff -u src/osd.c src/osd_new.c >> --- src/osd.c 2007-07-14 00:18:20.000000000 +0200 >> +++ src/osd_new.c 2008-08-06 21:26:09.000000000 +0200 >> @@ -515,6 +515,8 @@ >> { >> # if defined (WIN32) || defined (OS2) && defined (__IBMC__) >> int pid = _getpid (); >> +# elif defined (__APPLE__) >> + __darwin_pid_t pid = getpid (); > > Why do you need __darwin_pid_t here? Shouldn't just pid_t suffice? > > Roland you are right, it's sufficient. serenity:~ toxygen$ grep pid_t /usr/include/sys/types.h | grep -v _id_t typedef __darwin_pid_t pid_t; serenity:~ toxygen$ but pid_t is more correct I guess. Can someone commit it to cvs rep? Marian From ok at cs.otago.ac.nz Wed Aug 6 19:02:20 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 7 Aug 2008 14:02:20 +1200 Subject: [splint-discuss] Patch for splint to compile on mac os x In-Reply-To: <5E5607DA-0746-4A5C-BCDC-CB434BDA069C@gmail.com> References: <5E5607DA-0746-4A5C-BCDC-CB434BDA069C@gmail.com> Message-ID: <761FE91A-F381-4AD8-BD2F-1DF7ADD1E9D8@cs.otago.ac.nz> On 7 Aug 2008, at 6:59 am, Marian Such wrote: > Hello, > here is patch to make splint compile without error on Mac OS X. > > # diff -u src/osd.c src/osd_new.c Err, I have splint building in another window on a Mac OS X machine right now. osd.c *did* compile without error, without needing any patch. ... Yup, the whole thing built straight out of the box without needing any changes at all. > --- src/osd.c 2007-07-14 00:18:20.000000000 +0200 > +++ src/osd_new.c 2008-08-06 20:41:21.000000000 +0200 > @@ -515,6 +515,8 @@ > { > # if defined (WIN32) || defined (OS2) && defined (__IBMC__) > int pid = _getpid (); > +# elif __APPLE__ > + __darwin_pid_t pid = getpid (); > # else > __pid_t pid = getpid (); > # endif The code I see in a straight-out-of-the-box 3.1.2 distro is # if defined (WIN32) || defined (OS2) && defined (__IBMC__) int # else int /* pid_t */ # endif osd_getPid () { # if defined (WIN32) || defined (OS2) && defined (__IBMC__) int pid = _getpid (); # else pid_t pid = getpid (); # endif return (int) pid; } The *right* name for the type is indeed 'pid_t', not '__pid_t', as the Mac OS X 'man getpid' says (and as POSIX says also). Which version of SPlint? [for me, 3.1.2] Which version of Mac OS X? [for me, 10.5.4] Which version of XCode? [for me, 3.0] From splint at sympatico.ca Wed Aug 6 20:54:05 2008 From: splint at sympatico.ca (Bill Pringlemeir) Date: 06 Aug 2008 22:54:05 -0500 Subject: [splint-discuss] Patch for splint to compile on mac os x In-Reply-To: <9A42B97B-B028-4C2C-9FBD-364295158E2F@gmail.com> References: <5E5607DA-0746-4A5C-BCDC-CB434BDA069C@gmail.com> <279327B9-764C-432D-8C92-46D97773BC3D@gmail.com> <489A14A4.1080208@gmx.de> <9A42B97B-B028-4C2C-9FBD-364295158E2F@gmail.com> Message-ID: <87k5eth44i.fsf@sympatico.ca> On 6 Aug 2008, toxygen1 at gmail.com wrote: > > but pid_t is more correct I guess. Can someone commit it to cvs rep? > I believe the default case should work for your platform now. If a platform requires "__pid_t", then this should probably be conditional. I will have broken such a platform if it exists. revision 1.44 date: 2008/08/07 02:51:59; author: bpringlemeir; state: Exp; lines: +2 -2 Allow compile on apple platforms. osd.c Use pid_t instead of __pid_t as per open group. diff -r1.43 -r1.44 519c519 < __pid_t pid = getpid (); --- > pid_t pid = getpid (); 865c865 < #else if defined (OS2) --- > #elif defined (OS2) -- My cousin is an agoraphobic homosexual, which makes it kind of hard for him to come out of the closet. - Bill Kelly From toxygen1 at gmail.com Thu Aug 7 02:55:03 2008 From: toxygen1 at gmail.com (Marian Such) Date: Thu, 7 Aug 2008 11:55:03 +0200 Subject: [splint-discuss] Patch for splint to compile on mac os x In-Reply-To: <761FE91A-F381-4AD8-BD2F-1DF7ADD1E9D8@cs.otago.ac.nz> References: <5E5607DA-0746-4A5C-BCDC-CB434BDA069C@gmail.com> <761FE91A-F381-4AD8-BD2F-1DF7ADD1E9D8@cs.otago.ac.nz> Message-ID: <43503DDA-D0ED-4DB0-8F42-5062FB13E658@gmail.com> On Aug 7, 2008, at 4:02 AM, Richard A. O'Keefe wrote: > > On 7 Aug 2008, at 6:59 am, Marian Such wrote: > >> Hello, >> here is patch to make splint compile without error on Mac OS X. >> >> # diff -u src/osd.c src/osd_new.c > > Err, I have splint building in another window on a Mac OS X machine > right now. osd.c *did* compile without error, without needing any > patch. ... Yup, the whole thing built straight out of the box without > needing any changes at all. I was getting the very same error: http://www.cs.virginia.edu/pipermail/splint-discuss/2007-August/ 001027.html > >> --- src/osd.c 2007-07-14 00:18:20.000000000 +0200 >> +++ src/osd_new.c 2008-08-06 20:41:21.000000000 +0200 >> @@ -515,6 +515,8 @@ >> { >> # if defined (WIN32) || defined (OS2) && defined (__IBMC__) >> int pid = _getpid (); >> +# elif __APPLE__ >> + __darwin_pid_t pid = getpid (); >> # else >> __pid_t pid = getpid (); >> # endif > > The code I see in a straight-out-of-the-box 3.1.2 distro is > > # if defined (WIN32) || defined (OS2) && defined (__IBMC__) > int > # else > int /* pid_t */ > # endif > osd_getPid () > { > # if defined (WIN32) || defined (OS2) && defined (__IBMC__) > int pid = _getpid (); > # else > pid_t pid = getpid (); > # endif > > return (int) pid; > } > there is some culprit because I have different code after uncompressing source distribution (http://www.splint.org/downloads/ splint-3.1.2.src.tgz). this is what I have: # if defined (WIN32) || defined (OS2) && defined (__IBMC__) int # else int /* pid_t */ # endif osd_getPid () { # if defined (WIN32) || defined (OS2) && defined (__IBMC__) int pid = _getpid (); # else __pid_t pid = getpid (); <----- this is different # endif return (int) pid; } any idea? maybe it's fixed it cvs already? > The *right* name for the type is indeed 'pid_t', not > '__pid_t', as the Mac OS X 'man getpid' says (and as > POSIX says also). > > Which version of SPlint? [for me, 3.1.2] the same > Which version of Mac OS X? [for me, 10.5.4] 10.4.11 - this could be the cause > Which version of XCode? [for me, 3.0] xcode doesn't matter really. I have 2.4.1 compiler: gcc version 4.0.1 (Apple Computer, Inc. build 5367) Marian From toxygen1 at gmail.com Thu Aug 7 03:16:55 2008 From: toxygen1 at gmail.com (Marian Such) Date: Thu, 7 Aug 2008 12:16:55 +0200 Subject: [splint-discuss] Patch for splint to compile on mac os x In-Reply-To: <87k5eth44i.fsf@sympatico.ca> References: <5E5607DA-0746-4A5C-BCDC-CB434BDA069C@gmail.com> <279327B9-764C-432D-8C92-46D97773BC3D@gmail.com> <489A14A4.1080208@gmx.de> <9A42B97B-B028-4C2C-9FBD-364295158E2F@gmail.com> <87k5eth44i.fsf@sympatico.ca> Message-ID: <71CCA6DB-2290-4788-A84A-C6D6683606F5@gmail.com> Ok, I just did checkout from cvs and the code compiled flawlessly. regards Marian On Aug 7, 2008, at 5:54 AM, Bill Pringlemeir wrote: > On 6 Aug 2008, toxygen1 at gmail.com wrote: >> >> but pid_t is more correct I guess. Can someone commit it to cvs rep? >> > > I believe the default case should work for your platform now. If a > platform requires "__pid_t", then this should probably be conditional. > I will have broken such a platform if it exists. > > revision 1.44 > date: 2008/08/07 02:51:59; author: bpringlemeir; state: Exp; > lines: +2 -2 > Allow compile on apple platforms. osd.c > Use pid_t instead of __pid_t as per open group. > > diff -r1.43 -r1.44 > 519c519 > < __pid_t pid = getpid (); > --- >> pid_t pid = getpid (); > 865c865 > < #else if defined (OS2) > --- >> #elif defined (OS2) > > -- > My cousin is an agoraphobic homosexual, which makes it kind of hard > for him to come out of the closet. - Bill Kelly > > _______________________________________________ > splint-discuss mailing list > splint-discuss at mail.cs.virginia.edu > http://www.cs.virginia.edu/mailman/listinfo/splint-discuss From ofaurax at neotion.com Fri Aug 8 06:51:09 2008 From: ofaurax at neotion.com (Olivier FAURAX) Date: Fri, 08 Aug 2008 15:51:09 +0200 Subject: [splint-discuss] New user Message-ID: <489C4F4D.7070803@neotion.com> Hello ! I'm a new user, and my goal is just to use a "better lint", that is : no effort on annotation, only a weak check of my code (for the moment). I try to use splint, but I encounter parse errors everytime. The last time, it was on this line : void* y = (void*) malloc(x); What is difficult to parse here ? Thanks for your help Olivier FAURAX From lholzheid at bihl-wiedemann.de Fri Aug 8 07:47:55 2008 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Fri, 8 Aug 2008 16:47:55 +0200 Subject: [splint-discuss] New user In-Reply-To: <489C4F4D.7070803@neotion.com> References: <489C4F4D.7070803@neotion.com> Message-ID: <20080808144755.GA30493@svr5.bihl-wiedemann.de> On Fri, 2008-08-08 15:51:09 +0200, Olivier FAURAX wrote: > Hello ! > > I'm a new user, and my goal is just to use a "better lint", that is : no > effort on annotation, only a weak check of my code (for the moment). > > I try to use splint, but I encounter parse errors everytime. > The last time, it was on this line : void* y = (void*) malloc(x); > What is difficult to parse here ? I think splint _is_ able to parse lines like this. However, this looks to me like a C99/C++-style mixing of definitions and statements. I suppose there are statements (not definitions) above this line in the same block. This would violate C89/C90, which demands the definitions to appear at the beginning of a block, prior to the first statement. Splint can parse ANSI-C89/ISO-C90 code only, sorry. Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flo?w?rthstra?e 41 e-mail: lholzheid at bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- From Michael.Wojcik at microfocus.com Fri Aug 8 07:54:06 2008 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 8 Aug 2008 07:54:06 -0700 Subject: [splint-discuss] New user In-Reply-To: <489C4F4D.7070803@neotion.com> References: <489C4F4D.7070803@neotion.com> Message-ID: <11352F9641010A418AD5057945A3A6590118B7E5@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > Olivier FAURAX > Sent: Friday, 08 August, 2008 09:51 > > I try to use splint, but I encounter parse errors everytime. > The last time, it was on this line : void* y = (void*) > malloc(x); What is difficult to parse here ? Nothing. The following is passed by splint 3.1.1 with no errors or warnings, using the default settings: ----- #include static void foo(size_t x) { void *y = (void*) malloc(x); /* your example */ free(y); } int main(void) { foo(1); return 0; } ----- So presumably it is something else in your code, likely on a previous line, which is causing the problem. Note that casting the return value of malloc is bad practice. If a correct declaration for malloc is in scope, its return type is void *, which can be converted to any object pointer type on assignment. Casting the return value of malloc only serves to hide the error of failing to have a correct declaration in scope. (The one exception is for code that needs to be compiled as both C and C++. This is not common.) -- Michael Wojcik Principal Software Systems Developer, Micro Focus From lholzheid at bihl-wiedemann.de Fri Aug 8 10:46:03 2008 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Fri, 8 Aug 2008 19:46:03 +0200 Subject: [splint-discuss] New user In-Reply-To: <489C6792.5090907@neotion.com> References: <489C4F4D.7070803@neotion.com> <20080808144755.GA30493@svr5.bihl-wiedemann.de> <489C6792.5090907@neotion.com> Message-ID: <20080808174603.GA12808@svr5.bihl-wiedemann.de> On Fri, 2008-08-08 17:34:42 +0200, Olivier FAURAX wrote: > Ludolf Holzheid a ?crit : > >[..] > > > >Splint can parse ANSI-C89/ISO-C90 code only, sorry. > > Yes, I use C99 code. > That is bad news for me.... > > Do you know any C lint program that support C99 ? > Is it planned for splint ? If this is the only C99ism splint chokes on while checking your code: A few weeks ago a patch was posted to this list addressing it. See http://www.cs.virginia.edu/pipermail/splint-discuss/2008-July/001190.html. I didn't look at it yet, though. As far as I understood, full support for C99 is currently not planned. HTH, Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flo?w?rthstra?e 41 e-mail: lholzheid at bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- From JHolland at FASTSOFT.COM Fri Aug 8 11:40:50 2008 From: JHolland at FASTSOFT.COM (Jake Holland) Date: Fri, 8 Aug 2008 11:40:50 -0700 Subject: [splint-discuss] New user References: <489C4F4D.7070803@neotion.com> <20080808144755.GA30493@svr5.bihl-wiedemann.de> Message-ID: > Splint can parse ANSI-C89/ISO-C90 code only, sorry. I sent a patch a few weeks ago that worked around this particular issue. Michael Wojcik responded with the excellent critique that if splint is otherwise C90 and one change is introduced to make splint silently accept some code that's C99-legal and C90-illegal, that could be considered a false negative. (Thanks!) However, after reading Olivier Faurax's question earlier today, I searched for "splint c99" on google, and found that splint already appears to be a hybrid of c90/c99. For example: 1. search in the change log [http://www.splint.org/changes.html] for C99, to find several changes that cause splint to silently accept parts of c99. 2. The FAQ [http://www.splint.org/faq.html] states: "Splint is independent from your compiler. It checks standard C code, according to the ISO C99 specification. Splint supports most, but not all, of the C99 extensions to the ANSI C." 3. After reading the change log, I built a few sample programs, each of which produced no warnings from splint (run with no arguments besides the file name): /* sample.c, c99-legal, c90-illegal*/ #include struct evil_struct { int bad_integer; }; int main() { struct evil_struct s = { .bad_integer = 1 }; printf("%d\n", s.bad_integer); return 0; } /* eof */ /* sample2.c, does NOT compile with gcc (missing #include ) */ /* therefore, splint implicitly understands "bool" as a type! */ #include int main() { bool x = false; if (x) { printf("true\n"); } else { printf("false\n"); } return 0; } /* eof */ I also found several other messages indicating interest in a fix for this problem (besides the 2 in the past month): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369264 http://coding.derkeiler.com/Archive/C_CPP/comp.lang.c/2007-06/msg00917.h tml http://osdir.com/ml/programming.splint.general/2006-08/msg00000.html For these reasons, I submit that splint would become strictly better if it were extended to support this c99-ism, in addition to the others it supports. (Better still would be a cleaner and stricter differentiation of the different flavors of c, selected by a "--std={ansic89|isoc99}" option or something, but that would be more like a project than a patch...) So unless somebody can convince me otherwise, I guess I'm on a quest to find a splint maintainer if he exists, and perhaps get a new patch release out, as time permits. Of course, anyone who likes my patch is welcome to use it, and encouraged to send me feedback :) http://www.cs.virginia.edu/pipermail/splint-discuss/2008-July/001190.htm l From Michael.Wojcik at microfocus.com Fri Aug 8 12:36:27 2008 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 8 Aug 2008 12:36:27 -0700 Subject: [splint-discuss] New user In-Reply-To: References: <489C4F4D.7070803@neotion.com><20080808144755.GA30493@svr5.bihl-wiedemann.de> Message-ID: <11352F9641010A418AD5057945A3A6590118B7E6@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > Jake Holland > Sent: Friday, 08 August, 2008 14:41 > > > Splint can parse ANSI-C89/ISO-C90 code only, sorry. > > I sent a patch a few weeks ago that worked around this > particular issue. > > Michael Wojcik responded with the excellent critique that if > splint is otherwise C90 and one change is introduced to make > splint silently accept some code that's C99-legal and > C90-illegal, that could be considered a false negative. (Thanks!) > > However, after reading Olivier Faurax's question earlier > today, I searched for "splint c99" on google, and found that > splint already appears to be a hybrid of c90/c99. Huh. How about that. I had either never read that FAQ entry, or had forgotten about it. I'd think that makes your patch completely appropriate. (For that matter, it'd be nice if Splint accepted *all* of C99, or at least all the common bits. Mixed statements and declarations certainly seem to be common in C99 code.) -- Michael Wojcik Principal Software Systems Developer, Micro Focus From lholzheid at bihl-wiedemann.de Mon Aug 11 00:54:35 2008 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Mon, 11 Aug 2008 09:54:35 +0200 Subject: [splint-discuss] New user In-Reply-To: <11352F9641010A418AD5057945A3A6590118B7E6@MTV-EXCHANGE.microfocus.com> References: <11352F9641010A418AD5057945A3A6590118B7E6@MTV-EXCHANGE.microfocus.com> Message-ID: <20080811075435.GA22420@svr5.bihl-wiedemann.de> On Fri, 2008-08-08 12:36:27 -0700, Michael Wojcik wrote: > > From: splint-discuss-bounces at cs.virginia.edu > > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > > Jake Holland > > Sent: Friday, 08 August, 2008 14:41 > > > > [..] > > > > However, after reading Olivier Faurax's question earlier > > today, I searched for "splint c99" on google, and found that > > splint already appears to be a hybrid of c90/c99. > > Huh. How about that. I had either never read that FAQ entry, or had > forgotten about it. As far as I remember, the splint _parser_ is C89/C90 only, but the _libraries_ have been adapted for C99. That's why bool, uint8_t and friends are known by splint, but not mixed statements and declarations. > (For that matter, it'd be nice if Splint accepted *all* of C99, or at > least all the common bits. Mixed statements and declarations certainly > seem to be common in C99 code.) This would involve changing the parser, which is told to be non-trivial. Maybe replacing the current parser with e.g. sparse would be easier ... Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flo?w?rthstra?e 41 e-mail: lholzheid at bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- From ofaurax at neotion.com Mon Aug 11 01:23:10 2008 From: ofaurax at neotion.com (Olivier FAURAX) Date: Mon, 11 Aug 2008 10:23:10 +0200 Subject: [splint-discuss] where to find yylex ? Message-ID: <489FF6EE.50609@neotion.com> Hello, I think this is really a newbie question, but I can't manage to compile splint from source code because of missing yy* errors : cgrammar.o: In function `yyparse': /home/ofaurax/cvs/splint/src/cgrammar.c:4194: undefined reference to `yylex' I've flex and bison installed, correctly found by the ./configure. Perhaps the ./configure could have an additional check for the needed lib. Thanks for your work. Olivier From jakykong at theanythingbox.com Mon Aug 11 02:26:46 2008 From: jakykong at theanythingbox.com (Jack T Mudge III) Date: Mon, 11 Aug 2008 02:26:46 -0700 Subject: [splint-discuss] where to find yylex ? In-Reply-To: References: Message-ID: <200808110226.52509.jakykong@theanythingbox.com> On Monday 11 August 2008 01:53:54 am splint-discuss-request at cs.virginia.edu wrote: > Message: 9 > Date: Mon, 11 Aug 2008 10:23:10 +0200 > From: Olivier FAURAX > Subject: [splint-discuss] where to find yylex ? > To: splint-discuss at cs.virginia.edu > Message-ID: <489FF6EE.50609 at neotion.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, > > I think this is really a newbie question, but I can't manage to compile > splint from source code because of missing yy* errors : > cgrammar.o: In function `yyparse': > /home/ofaurax/cvs/splint/src/cgrammar.c:4194: undefined reference to > `yylex' > > I've flex and bison installed, correctly found by the ./configure. > > Perhaps the ./configure could have an additional check for the needed > lib. > > Thanks for your work. > Olivier I believe the issue is that you need to first run bison and flex to generate the header files that contain those definitions. Splint, just like the compiler, can only deal with what it already knows about -- and those declarations, the yy* ones, are created by bison and flex. At least for my programs, I typically run bison and flex and end up with files such as "lex.yy.c" and "lex.yy.h" from flex and "yacc.yy.c" and "yacc.yy.h" from bison. The .h files are included in my source file(s), and that's how splint knows about the functions (etc). Once you run flex and bison, it's all C from there. Hope it helps! -- Sincerely, Jack Mudge jakykong at theanythingbox.com GPG Pubkey ID: 0x78BEC84C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080811/4c56bda0/attachment.bin From lholzheid at bihl-wiedemann.de Mon Aug 11 02:51:48 2008 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Mon, 11 Aug 2008 11:51:48 +0200 Subject: [splint-discuss] where to find yylex ? In-Reply-To: <200808110226.52509.jakykong@theanythingbox.com> References: <200808110226.52509.jakykong@theanythingbox.com> Message-ID: <20080811095148.GB24504@svr5.bihl-wiedemann.de> On Mon, 2008-08-11 02:26:46 -0700, Jack T Mudge III wrote: > On Monday 11 August 2008 01:53:54 am splint-discuss-request at cs.virginia.edu > wrote: > > Message: 9 > > Date: Mon, 11 Aug 2008 10:23:10 +0200 > > From: Olivier FAURAX > > Subject: [splint-discuss] where to find yylex ? > > To: splint-discuss at cs.virginia.edu > > Message-ID: <489FF6EE.50609 at neotion.com> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > Hello, > > > > I think this is really a newbie question, but I can't manage to compile > > splint from source code because of missing yy* errors : > > cgrammar.o: In function `yyparse': > > /home/ofaurax/cvs/splint/src/cgrammar.c:4194: undefined reference to > > `yylex' > > > > I've flex and bison installed, correctly found by the ./configure. > > > > Perhaps the ./configure could have an additional check for the needed > > lib. > > > > Thanks for your work. > > Olivier > > I believe the issue is that you need to first run bison and flex to generate > the header files that contain those definitions. Splint, just like the > compiler, can only deal with what it already knows about -- and those > declarations, the yy* ones, are created by bison and flex. Jack, Olivier gets these errors while _compiling_ splint, not _using_ it. The question is, why the build system doesn't succeed in calling flex, but nevertheless tries to link. (Olivier didn't mention if the message is generated by the compiler or the linker, but it 'looks to me' as a linker message.) I suppose something went wrong with the flex output post-processing (using sed), which rendered cscanner.c being empty (or incomplete). Maybe deleting cscanner.c and re-building helps ... Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flo?w?rthstra?e 41 e-mail: lholzheid at bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080811/50ad1aa9/attachment.bin From lholzheid at bihl-wiedemann.de Mon Aug 11 02:51:48 2008 From: lholzheid at bihl-wiedemann.de (Ludolf Holzheid) Date: Mon, 11 Aug 2008 11:51:48 +0200 Subject: [splint-discuss] where to find yylex ? In-Reply-To: <200808110226.52509.jakykong@theanythingbox.com> References: <200808110226.52509.jakykong@theanythingbox.com> Message-ID: <20080811095148.GB24504@svr5.bihl-wiedemann.de> On Mon, 2008-08-11 02:26:46 -0700, Jack T Mudge III wrote: > On Monday 11 August 2008 01:53:54 am splint-discuss-request at cs.virginia.edu > wrote: > > Message: 9 > > Date: Mon, 11 Aug 2008 10:23:10 +0200 > > From: Olivier FAURAX > > Subject: [splint-discuss] where to find yylex ? > > To: splint-discuss at cs.virginia.edu > > Message-ID: <489FF6EE.50609 at neotion.com> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > Hello, > > > > I think this is really a newbie question, but I can't manage to compile > > splint from source code because of missing yy* errors : > > cgrammar.o: In function `yyparse': > > /home/ofaurax/cvs/splint/src/cgrammar.c:4194: undefined reference to > > `yylex' > > > > I've flex and bison installed, correctly found by the ./configure. > > > > Perhaps the ./configure could have an additional check for the needed > > lib. > > > > Thanks for your work. > > Olivier > > I believe the issue is that you need to first run bison and flex to generate > the header files that contain those definitions. Splint, just like the > compiler, can only deal with what it already knows about -- and those > declarations, the yy* ones, are created by bison and flex. Jack, Olivier gets these errors while _compiling_ splint, not _using_ it. The question is, why the build system doesn't succeed in calling flex, but nevertheless tries to link. (Olivier didn't mention if the message is generated by the compiler or the linker, but it 'looks to me' as a linker message.) I suppose something went wrong with the flex output post-processing (using sed), which rendered cscanner.c being empty (or incomplete). Maybe deleting cscanner.c and re-building helps ... Ludolf -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flo?w?rthstra?e 41 e-mail: lholzheid at bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080811/50ad1aa9/attachment-0001.bin From ofaurax at neotion.com Mon Aug 11 03:06:58 2008 From: ofaurax at neotion.com (Olivier FAURAX) Date: Mon, 11 Aug 2008 12:06:58 +0200 Subject: [splint-discuss] where to find yylex ? In-Reply-To: <20080811095148.GB24504@svr5.bihl-wiedemann.de> References: <200808110226.52509.jakykong@theanythingbox.com> <20080811095148.GB24504@svr5.bihl-wiedemann.de> Message-ID: <48A00F42.1010707@neotion.com> Ludolf Holzheid a ?crit : > I suppose something went wrong with the flex output post-processing > (using sed), which rendered cscanner.c being empty (or > incomplete). Maybe deleting cscanner.c and re-building helps ... I removed this one, and I removed the last \ of the comment of the last line on test/Makefile.am and it worked well... thanks ! Olivier From JHolland at FASTSOFT.COM Mon Aug 11 11:10:45 2008 From: JHolland at FASTSOFT.COM (Jake Holland) Date: Mon, 11 Aug 2008 11:10:45 -0700 Subject: [splint-discuss] c99 (was New User) References: <11352F9641010A418AD5057945A3A6590118B7E6@MTV-EXCHANGE.microfocus.com> <20080811075435.GA22420@svr5.bihl-wiedemann.de> Message-ID: >> (For that matter, it'd be nice if Splint accepted *all* of C99, or at >> least all the common bits. Mixed statements and declarations certainly >> seem to be common in C99 code.) > >This would involve changing the parser, which is told to be >non-trivial. Maybe replacing the current parser with e.g. sparse would >be easier ... >From the parts of the parser I saw while making that patch, I would guess the difficulty is not in parsing C correctly, but rather in making the right calls from the parser to make sure splint's internal data structures are built properly during the parsing. I would further guess that this does not get easier by using a different front-end. There are also some non-standard extensions that presumably would not be present in another front-end. It's not obvious to me how many there are, or how hard it would be to port their functionality into a new parser. There might be more, but the ones I think I saw were: 1. QNOTREACHED: I'm pretty sure it's not part of a normal C parser. It seems to be some kind of non-reachable code detection that's done inside the parser itself, rather than in post-processing of the parse structures. 2. There's some macro handling inside the parser which would ordinarily be expanded in a pre-processor. Depending how much more is necessary to get good c99 coverage, it might be significantly easier to continue patching the existing parser. I don't suppose anybody knows of a list of c99 constructs that splint does not support properly? Maybe it would be worth running through the gcc c-torture tests to get a first cut, but analyzing that is probably more time than I have today... From Michael.Wojcik at MicroFocus.com Mon Aug 11 15:06:51 2008 From: Michael.Wojcik at MicroFocus.com (Michael Wojcik) Date: Mon, 11 Aug 2008 15:06:51 -0700 Subject: [splint-discuss] c99 (was New User) In-Reply-To: References: <11352F9641010A418AD5057945A3A6590118B7E6@MTV-EXCHANGE.microfocus.com><20080811075435.GA22420@svr5.bihl-wiedemann.de> Message-ID: <11352F9641010A418AD5057945A3A6590118B7EF@MTV-EXCHANGE.microfocus.com> > From: splint-discuss-bounces at cs.virginia.edu > [mailto:splint-discuss-bounces at cs.virginia.edu] On Behalf Of > Jake Holland > Sent: Monday, 11 August, 2008 14:11 > > I don't suppose anybody knows of a list of c99 constructs > that splint does not support properly? I don't, but there's a handy short list of what C99 changed from the previous standard at: http://home.datacomm.ch/t_wolf/tw/c/c9x_changes.html That would help write a shorter set of tests. (I'd put a suite together myself if I weren't tied up with about a million other things right now.) -- Michael Wojcik Principal Software Systems Developer, Micro Focus