From PRumble at ndsuk.com Thu Apr 1 11:04:08 2004 From: PRumble at ndsuk.com (Rumble, Phil) Date: Wed Mar 22 17:10:27 2006 Subject: [splint-discuss] NEWBIE - Files of the same name Message-ID: I have recently started to use splint. I have a situation whereby there are two different files with the same name. The two files have guards so if the other file is parsed first then second is ignored. It should be that one library is built with one file parsed first and then a second library is built with the other file. How do I make splint parse the files in the correct order. I thought that the include path order would do the trick, but it does not seem that way. I am using splint for Win32 version 3.1.1. Also is there anyway to use splint to parse libraries of code rather than the complete code base. Thanks in Advance Rumble ======================================================= Information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by email to postmaster@ndsuk.com and destroy the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20040401/58151574/attachment.htm From cbfalconer at yahoo.com Fri Apr 2 00:52:46 2004 From: cbfalconer at yahoo.com (CBFalconer) Date: Wed Mar 22 17:10:28 2006 Subject: [splint-discuss] Undetected incomplete deallocation References: <4067EB60.5010401@thales-e-transactions.com> Message-ID: <406CFFAE.E05EF7D0@yahoo.com> Bertrand ANSEAUME wrote: > > I have a problem to detect incomplete deallocation of a structure > that includes two buffers buf1 and buf2 (see code sample below). > If I don't release buf1 and buf2, Splint correctly detects the two > memory leaks. But if I release buf1 only, Splint does not detect > buf2 memory leak. Any idea? > > ----------------------------- > typedef struct _Mystruct > { > /*@only@*/ char* buf1; > /*@only@*/ char* buf2; > } Mystruct; > > > /*@only@*/ Mystruct* Mystruct_new(void) > { > Mystruct* mystruct; > mystruct = (Mystruct*)malloc(sizeof *mystruct); mystruct = malloc(sizeof *mystruct); > assert(mystruct != NULL); > > mystruct->buf1 = (char*)malloc(256); mystruct->buf1 = malloc(256); > assert(mystruct->buf1 != NULL); > memset(mystruct->buf1, 0, 256); > > mystruct->buf2 = (char*)malloc(256); mystruct->buf2 = malloc(256); > assert(mystruct->buf2 != NULL); > memset(mystruct->buf2, 0, 256); > > return mystruct; > } > > void Mystruct_free(/*@only@*/ Mystruct* mystruct) > { > free(mystruct->buf1); > free(mystruct); > /* Undetected memory leak : buf2 is not released!!!!*/ > } > ---------------------------------- You didn't supply a compilable and executable extract, so I don't know if the above changes will make any difference. At any rate, you should never cast the return from malloc, it serves no purpose other than to prevent error diagnosis by the compiler. If you get errors or warnings you are either using a C++ compiler, or have failed to #include stdlib.h. Both are errors. -- Churchill and Bush can both be considered wartime leaders, just as Secretariat and Mr Ed were both horses. - James Rhodes. From bertrand.anseaume at thales-e-transactions.com Fri Apr 2 07:01:54 2004 From: bertrand.anseaume at thales-e-transactions.com (Bertrand ANSEAUME) Date: Wed Mar 22 17:10:28 2006 Subject: [splint-discuss] Undetected incomplete deallocation References: <4067EB60.5010401@thales-e-transactions.com> <406CFFAE.E05EF7D0@yahoo.com> Message-ID: <406D5632.4010600@thales-e-transactions.com> Thanks for the advice. I will avoid casting malloc return for now on. And you are right : includes are missing in the sample extract I provided (stdlib, string and assert). Anyhow, it does not solve my Splint issue... CBFalconer a ?crit: >Bertrand ANSEAUME wrote: > > >>I have a problem to detect incomplete deallocation of a structure >>that includes two buffers buf1 and buf2 (see code sample below). >>If I don't release buf1 and buf2, Splint correctly detects the two >>memory leaks. But if I release buf1 only, Splint does not detect >>buf2 memory leak. Any idea? >> >>[...] >> >> >You didn't supply a compilable and executable extract, so I don't >know if the above changes will make any difference. At any rate, >you should never cast the return from malloc, it serves no purpose >other than to prevent error diagnosis by the compiler. If you get >errors or warnings you are either using a C++ compiler, or have >failed to #include stdlib.h. Both are errors. > > > From btremaine at capellaphotonics.com Thu Apr 8 13:32:02 2004 From: btremaine at capellaphotonics.com (Brian Tremaine) Date: Wed Mar 22 17:10:28 2006 Subject: [splint-discuss] splintrc Message-ID: <832829693E0F6B409DB49DBFECA072FE081242@capella-exch.capellaphotonics.com> I'm a new user of splint and would like to find a splintrc file for TI Code Composer. I'm developing C code for the C6700 family DSP. Thanks, Brian This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Capella Photonics Inc. From cbfalconer at yahoo.com Fri Apr 9 09:18:40 2004 From: cbfalconer at yahoo.com (CBFalconer) Date: Wed Mar 22 17:10:28 2006 Subject: [splint-discuss] splintrc References: <832829693E0F6B409DB49DBFECA072FE081242@capella-exch.capellaphotonics.com> Message-ID: <4076A2B0.924AF0E5@yahoo.com> Brian Tremaine wrote: > > I'm a new user of splint and would like to find a splintrc file for > TI Code Composer. I'm developing C code for the C6700 family DSP. I think you have a misconception of the purpose of splint. It checks for possible ambiguities and non-portabilities, not for compliance with some particular compiler. The compiler itself does that job. Splint warnings focus your attention on particular areas, so you can decide "did I really mean that". System headers normally contain many highly questionable constructs, which work only with that particular system and compiler, and thus would be flagged. So the principle customization requirement is to ignore errors/warnings in those areas. > > This email message is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. Any unauthorized review, > use, disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy all copies > of the original message. Capella Photonics Inc. This is totally pointless in newsgroups and mailling lists. Please remove it. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From Brian.Thorpe at tait.co.nz Mon Apr 12 16:43:11 2004 From: Brian.Thorpe at tait.co.nz (Brian Thorpe) Date: Wed Mar 22 17:10:28 2006 Subject: [splint-discuss] splintrc References: <832829693E0F6B409DB49DBFECA072FE081242@capella-exch.capellaphotonics.com> <4076A2B0.924AF0E5@yahoo.com> Message-ID: <407AFF5F.440CF5F7@tait.co.nz> CBFalconer wrote: > Brian Tremaine wrote: > > > > I'm a new user of splint and would like to find a splintrc file for > > TI Code Composer. I'm developing C code for the C6700 family DSP. > > I think you have a misconception of the purpose of splint. It > checks for possible ambiguities and non-portabilities, not for > compliance with some particular compiler. The compiler itself > does that job. Splint warnings focus your attention on particular > areas, so you can decide "did I really mean that". > > System headers normally contain many highly questionable > constructs, which work only with that particular system and > compiler, and thus would be flagged. So the principle > customization requirement is to ignore errors/warnings in those > areas. > > > > > This email message is for the sole use of the intended recipient(s) and may > > contain confidential and privileged information. Any unauthorized review, > > use, disclosure or distribution is prohibited. If you are not the intended > > recipient, please contact the sender by reply email and destroy all copies > > of the original message. Capella Photonics Inc. > > > This is totally pointless in newsgroups and mailling lists. > Please remove it. Can't this sometimes be appended automatically by the sender's company, in which case the sender has no control over its generation ? So asking them to remove it is pointless in itself. A more friendly and less aggressive tone to your emails might generate a better response CB. A: Know-alls. Q: What is the most annoying thing on usenet and in e-mail? > > > -- > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss From dwh at ovro.caltech.edu Tue Apr 13 17:30:16 2004 From: dwh at ovro.caltech.edu (David Hawkins) Date: Wed Mar 22 17:10:29 2006 Subject: [splint-discuss] Parse error with Linux pthreads In-Reply-To: Message-ID: Hi, Given the following command line arguments (RedHat Linux 9.0 machine, Linux 2.4.20-8 kernel): splint +posixlib buffer_queue.c -I../boolean where I have used a pthread_mutex_t inside the buffer queue implementation to protect it. I'm getting the following parse error Splint 3.0.1.7 --- 24 Jan 2003 /usr/include/bits/sigthread.h:33:18: Parse Error: Inconsistent function parameter syntax: __sigset_t : . (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. What can I do to eliminate this error? Thanks! Dave Hawkins. Caltech. From dwh at ovro.caltech.edu Tue Apr 13 18:10:56 2004 From: dwh at ovro.caltech.edu (David Hawkins) Date: Wed Mar 22 17:10:29 2006 Subject: [splint-discuss] Parse error with Linux pthreads (code example) In-Reply-To: Message-ID: Hi, > Given the following command line arguments > (RedHat Linux 9.0 machine, Linux 2.4.20-8 kernel): > > splint +posixlib buffer_queue.c -I../boolean > > where I have used a pthread_mutex_t inside the > buffer queue implementation to protect it. > > I'm getting the following parse error > > Splint 3.0.1.7 --- 24 Jan 2003 > > /usr/include/bits/sigthread.h:33:18: Parse Error: > Inconsistent function parameter syntax: __sigset_t : > . (For help on parse errors, see splint -help parseerrors.) > *** Cannot continue. > > What can I do to eliminate this error? I've upgraded to Splint 3.1.1, but still get the error. Below is a minimal compilable test program. Assuming this code was in debug.c, 'splint +posixlib debug.c' gives the same parse error as above. #include static pthread_mutex_t mutex; /* Create */ int init(void) { int status; /* mutex */ status = pthread_mutex_init(&mutex, NULL); return status; } /* Destroy */ int destroy(void) { int status; /* mutex */ status = pthread_mutex_destroy(&mutex); return status; } I'll keep looking on www.splint.org for suggestions, but if anyone can help, I'd appreciate it! Cheers Dave Hawkins Caltech. From cbfalconer at yahoo.com Tue Apr 13 23:01:03 2004 From: cbfalconer at yahoo.com (CBFalconer) Date: Wed Mar 22 17:10:29 2006 Subject: [splint-discuss] Parse error with Linux pthreads (code example) References: Message-ID: <407CA96F.371D2A8C@yahoo.com> David Hawkins wrote: > >> Given the following command line arguments >> (RedHat Linux 9.0 machine, Linux 2.4.20-8 kernel): >> >> splint +posixlib buffer_queue.c -I../boolean >> >> where I have used a pthread_mutex_t inside the >> buffer queue implementation to protect it. >> >> I'm getting the following parse error >> >> Splint 3.0.1.7 --- 24 Jan 2003 >> >> /usr/include/bits/sigthread.h:33:18: Parse Error: >> Inconsistent function parameter syntax: __sigset_t : >> . (For help on parse errors, see splint -help parseerrors.) >> *** Cannot continue. >> >> What can I do to eliminate this error? > > I've upgraded to Splint 3.1.1, but still get the error. > Below is a minimal compilable test program. Assuming this code > was in debug.c, 'splint +posixlib debug.c' gives the > same parse error as above. > > #include > static pthread_mutex_t mutex; > > /* Create */ > int init(void) > { > int status; > > /* mutex */ > status = pthread_mutex_init(&mutex, NULL); > return status; > } > > /* Destroy */ > int destroy(void) > { > int status; > > /* mutex */ > status = pthread_mutex_destroy(&mutex); > return status; > } > > I'll keep looking on www.splint.org for suggestions, but > if anyone can help, I'd appreciate it! As far as I can see you don't show the line(s) that trigger the parse error. If the fault is in the system headers, then you should see what (if any) extensions are being used therein. The name __sigset_t is in the system namespace. In general system headers should not be checked by splint. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! From Saravana.Rathinam at delphi.com Wed Apr 14 02:17:31 2004 From: Saravana.Rathinam at delphi.com (Saravana.Rathinam) Date: Wed Mar 22 17:10:29 2006 Subject: [splint-discuss] Parse error with Linux pthreads (code example) Message-ID: <05256E76.002255CB.00@notes.delphiauto.com> >David Hawkins wrote: >> >>> Given the following command line arguments >>> (RedHat Linux 9.0 machine, Linux 2.4.20-8 kernel): >>> >>> splint +posixlib buffer_queue.c -I../boolean >>> >>> where I have used a pthread_mutex_t inside the >>> buffer queue implementation to protect it. >>> >>> I'm getting the following parse error >>> >>> Splint 3.0.1.7 --- 24 Jan 2003 >>> >>> /usr/include/bits/sigthread.h:33:18: Parse Error: >>> Inconsistent function parameter syntax: __sigset_t : >>> . (For help on parse errors, see splint -help parseerrors.) >>> *** Cannot continue. >>> >>> What can I do to eliminate this error? >> --- > >As far as I can see you don't show the line(s) that trigger the >parse error. If the fault is in the system headers, then you >should see what (if any) extensions are being used therein. The >name __sigset_t is in the system namespace. > >In general system headers should not be checked by splint. Hi If this can be of any help. I have Splint 3.1.1 --- 02 May 2003 on Cygwin version 2.340.2.5. and splint gives a parse error in, pthread.h file: ------------------------ [joy ~ ]$splint +posixlib debug.c Splint 3.1.1 --- 02 May 2003 /usr/include/pthread.h:72:43: Parse Error. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. ---------------------- /usr/include/pthread.h 67:#define PTHREAD_SCOPE_PROCESS 0 68:#define PTHREAD_SCOPE_SYSTEM 1 70: 71: /* Attributes */ 72: int pthread_attr_destroy (pthread_attr_t *); 73: int pthread_attr_getdetachstate (const pthread_attr_t *, int *); 74: int pthread_attr_getinheritsched (const pthread_attr_t *, int *); 75: int pthread_attr_getschedparam (const pthread_attr_t *, struct sched_param *); 76: int pthread_attr_getschedpolicy (const pthread_attr_t *, int *); ---------------------- and this was the source file, debug.c ------------------------ #include static pthread_mutex_t mutex; /* Create */ int init(void) { int status; /* mutex */ status = pthread_mutex_init(&mutex, NULL); return status; } /* Destroy */ int destroy(void) { int status; /* mutex */ status = pthread_mutex_destroy(&mutex); return status; } /* Added main here to compile with gcc */ int main(void) { return 0; } ---------------------- The code compiles successfully in gcc, so is this a problem with splint? Saravana **************************************************************************************** Note: The information contained in this message may be privileged and confidential and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. **************************************************************************************** From cbfalconer at yahoo.com Wed Apr 14 08:36:40 2004 From: cbfalconer at yahoo.com (CBFalconer) Date: Wed Mar 22 17:10:29 2006 Subject: [splint-discuss] Parse error with Linux pthreads (code example) References: <05256E76.002255CB.00@notes.delphiauto.com> Message-ID: <407D3058.5BD4C6A3@yahoo.com> "Saravana.Rathinam" wrote: >> David Hawkins wrote: >>> >>>> Given the following command line arguments >>>> (RedHat Linux 9.0 machine, Linux 2.4.20-8 kernel): >>>> >>>> splint +posixlib buffer_queue.c -I../boolean >>>> >>>> where I have used a pthread_mutex_t inside the >>>> buffer queue implementation to protect it. >>>> >>>> I'm getting the following parse error >>>> >>>> Splint 3.0.1.7 --- 24 Jan 2003 >>>> >>>> /usr/include/bits/sigthread.h:33:18: Parse Error: >>>> Inconsistent function parameter syntax: __sigset_t : >>>> . (For help on parse errors, see splint -help parseerrors.) >>>> *** Cannot continue. >>>> >>>> What can I do to eliminate this error? >> >> As far as I can see you don't show the line(s) that trigger the >> parse error. If the fault is in the system headers, then you >> should see what (if any) extensions are being used therein. The >> name __sigset_t is in the system namespace. >> >> In general system headers should not be checked by splint. > > I have Splint 3.1.1 --- 02 May 2003 on Cygwin version 2.340.2.5. > and splint gives a parse error in, pthread.h file: > > ------------------------ > [joy ~ ]$splint +posixlib debug.c > Splint 3.1.1 --- 02 May 2003 > > /usr/include/pthread.h:72:43: Parse Error. (For help on parse > errors, see splint -help parseerrors.) > *** Cannot continue. > ---------------------- > > /usr/include/pthread.h > > 67:#define PTHREAD_SCOPE_PROCESS 0 > 68:#define PTHREAD_SCOPE_SYSTEM 1 > 70: > 71: /* Attributes */ > 72: int pthread_attr_destroy (pthread_attr_t *); > 73: int pthread_attr_getdetachstate (const pthread_attr_t *, int *); > 74: int pthread_attr_getinheritsched (const pthread_attr_t *, int *); > 75: int pthread_attr_getschedparam (const pthread_attr_t *, struct sched_param > *); > 76: int pthread_attr_getschedpolicy (const pthread_attr_t *, int *); > ... snip ... > > The code compiles successfully in gcc, so is this a problem with splint? I don't necessarily think so. I rarely use cygwin, but here, on grepping for pthread_attr_t, I find it in sys\types.h, and it in turn refers to struct sched_param, which is not defined. Note this is not a pointer referral, so the size of struct sched_param, and thence pthread_attr_t, cannot be known. I think it is a case of requiring an inclusion order in system headers, which is a nono. It may really be a gcc bug, or rather gcc porting bug. sched_param in turn seems to be defined in sys/sched_h, so a work-around might be to #include that before pthread.h If I am correct please make sure it is reported to the gcc team. At the same time the fault might be that splint requires macro constructs to be defined on expansion, which would again contravene the standard. There seems to be no need for splint to know the size of pthread_attr_t while inputting its definition. The OP's failure seems to have exhibited this behavior. Also, splint may be requiring the size while generating a call using a pointer to such a structure, which is faulty since all pointers to structures have the same size. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! From dwh at ovro.caltech.edu Wed Apr 14 13:25:40 2004 From: dwh at ovro.caltech.edu (David Hawkins) Date: Wed Mar 22 17:10:29 2006 Subject: [splint-discuss] Parse error with Linux pthreads In-Reply-To: <407D3058.5BD4C6A3@yahoo.com> Message-ID: Hi Chuck, Regarding the pthread example code I posted, you wrote: > As far as I can see you don't show the line(s) that trigger the > parse error. If the fault is in the system headers, then you > should see what (if any) extensions are being used therein. The > name __sigset_t is in the system namespace. > > In general system headers should not be checked by splint. As you know, the error was caused by splint parsing which in turn included /usr/include/bits/sigthread.h, and the parse error was over the function definition for pthread_sigmask() located within that header. extern int pthread_sigmask (int __how, __const __sigset_t *__restrict __newmask, __sigset_t *__restrict __oldmask)__THROW; I had assumed that the command line option +posixlib or +posixstrictlib would operate such that any parsing or Linux specific implementation details had already been dealt with in splint. > In general system headers should not be checked by splint. In this case, what would the recommended command line option be to avoid such checks? >From your second post, in response to Saravana, you additionally suggest : > I don't necessarily think so. I rarely use cygwin, but here, on > grepping for pthread_attr_t, I find it in sys\types.h, and it in > turn refers to struct sched_param, which is not defined. Note > this is not a pointer referral, so the size of struct sched_param, > and thence pthread_attr_t, cannot be known. I think it is a case > of requiring an inclusion order in system headers, which is a > nono. It may really be a gcc bug, or rather gcc porting bug. > > sched_param in turn seems to be defined in sys/sched_h, so a > work-around might be to #include that before pthread.h > > If I am correct please make sure it is reported to the gcc team. > > At the same time the fault might be that splint requires macro > constructs to be defined on expansion, which would again > contravene the standard. There seems to be no need for splint to > know the size of pthread_attr_t while inputting its definition. > The OP's failure seems to have exhibited this behavior. > > Also, splint may be requiring the size while generating a call > using a pointer to such a structure, which is faulty since all > pointers to structures have the same size. It appears that Cygwin has a slightly different problem, given that splint gets a parse error in pthread.h directly, as opposed to in bits/sigthread.h. I just ran the test under Cygwin, and saw a similar error, but looking at phthread.h, the file appears to already include the files you suggested: #include #include #include Either way, this is not the same error as under Linux. I guess the simplest method would be to not parse system headers. If you could suggest how to achieve that, I'd appreciate it. Thanks for taking the time to respond. I appreciate it. Regards Dave Hawkins Caltech. From raymundo.urenda at delphi.com Wed Apr 14 15:30:46 2004 From: raymundo.urenda at delphi.com (raymundo.urenda) Date: Wed Mar 22 17:10:29 2006 Subject: [splint-discuss] Parse error with Linux pthreads Message-ID: <7A44C0982758764BB7640CBCB255882D134977@mxchihjrz-ex03.NorthAmerica.DelphiAuto.net> Hi I'm new to splint, and I need to know if there is any way to get information about variables defined in a file but not used in the project. I do not need other information but this. Tahnk you for your help -----Original Message----- From: splint-discuss-bounces@cs.virginia.edu [mailto:splint-discuss-bounces@cs.virginia.edu]On Behalf Of David Hawkins Sent: Wednesday, April 14, 2004 11:26 AM To: splint-discuss@cs.virginia.edu Subject: RE: [splint-discuss] Parse error with Linux pthreads Hi Chuck, Regarding the pthread example code I posted, you wrote: > As far as I can see you don't show the line(s) that trigger the > parse error. If the fault is in the system headers, then you > should see what (if any) extensions are being used therein. The > name __sigset_t is in the system namespace. > > In general system headers should not be checked by splint. As you know, the error was caused by splint parsing which in turn included /usr/include/bits/sigthread.h, and the parse error was over the function definition for pthread_sigmask() located within that header. extern int pthread_sigmask (int __how, __const __sigset_t *__restrict __newmask, __sigset_t *__restrict __oldmask)__THROW; I had assumed that the command line option +posixlib or +posixstrictlib would operate such that any parsing or Linux specific implementation details had already been dealt with in splint. > In general system headers should not be checked by splint. In this case, what would the recommended command line option be to avoid such checks? >From your second post, in response to Saravana, you additionally suggest : > I don't necessarily think so. I rarely use cygwin, but here, on > grepping for pthread_attr_t, I find it in sys\types.h, and it in > turn refers to struct sched_param, which is not defined. Note > this is not a pointer referral, so the size of struct sched_param, > and thence pthread_attr_t, cannot be known. I think it is a case > of requiring an inclusion order in system headers, which is a > nono. It may really be a gcc bug, or rather gcc porting bug. > > sched_param in turn seems to be defined in sys/sched_h, so a > work-around might be to #include that before pthread.h > > If I am correct please make sure it is reported to the gcc team. > > At the same time the fault might be that splint requires macro > constructs to be defined on expansion, which would again > contravene the standard. There seems to be no need for splint to > know the size of pthread_attr_t while inputting its definition. > The OP's failure seems to have exhibited this behavior. > > Also, splint may be requiring the size while generating a call > using a pointer to such a structure, which is faulty since all > pointers to structures have the same size. It appears that Cygwin has a slightly different problem, given that splint gets a parse error in pthread.h directly, as opposed to in bits/sigthread.h. I just ran the test under Cygwin, and saw a similar error, but looking at phthread.h, the file appears to already include the files you suggested: #include #include #include Either way, this is not the same error as under Linux. I guess the simplest method would be to not parse system headers. If you could suggest how to achieve that, I'd appreciate it. Thanks for taking the time to respond. I appreciate it. Regards Dave Hawkins Caltech. _______________________________________________ splint-discuss mailing list splint-discuss@cs.virginia.edu http://www.splint.org/mailman/listinfo/splint-discuss **************************************************************************************** Note: The information contained in this message may be privileged and confidential and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. **************************************************************************************** From Saravana.Rathinam at delphi.com Thu Apr 15 04:07:33 2004 From: Saravana.Rathinam at delphi.com (Saravana.Rathinam) Date: Wed Mar 22 17:10:29 2006 Subject: [splint-discuss] Parse error with Linux pthreads (code example) Message-ID: <05256E77.002C7FD9.00@notes.delphiauto.com> Hi In continuation with the Linux pthreads problem. The following can be of valuable input in solving it. > Simple test file. /~~~~~~~~~~~~~~~~~~~~~~~~~~~ [joy ~/bug/types ]$cat test.c #include int main(void) { return 0; } ~~~~~~~~~~~~~~~~~~~~~~~~~~~/ /~~~~~~~~~~~~~~~~~~~~~~~~~~~ [joy ~/bug/types ]$splint test.c Splint 3.1.1 --- 02 May 2003 Finished checking --- no warnings ~~~~~~~~~~~~~~~~~~~~~~~~~~~/ | With -nolib option. /~~~~~~~~~~~~~~~~~~~~~~~~~~~ [joy ~/bug/types ]$splint -nolib test.c Splint 3.1.1 --- 02 May 2003 /usr/include/sys/_types.h:30:11: Parse Error. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. ~~~~~~~~~~~~~~~~~~~~~~~~~~~/ | Save temporary files /~~~~~~~~~~~~~~~~~~~~~~~~~~~ [joy ~/bug/types ]$splint -nolib +keep test.c Splint 3.1.1 --- 02 May 2003 /usr/include/sys/_types.h:30:11: Parse Error. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. Temporary files kept: /cygdrive/e/bug/types/test.c:1 /tmp/cl84AAA.c:1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~/ | Try compiling the splint preprocessed file with gcc. /~~~~~~~~~~~~~~~~~~~~~~~~~~~ [joy ~/bug/types ]$gcc /tmp/cl84AAA.c In file included from /usr/include/sys/reent.h:14, from /usr/include/stdio.h:45, from /cygdrive/e/bug/types/test.c:1: /usr/include/sys/_types.h:30: parse error before "wint_t" /usr/include/sys/_types.h:30: warning: no semicolon at end of struct or union /usr/include/sys/_types.h:30: warning: no semicolon at end of struct or union /usr/include/sys/_types.h:32: parse error before '}' token /usr/include/sys/_types.h:32: warning: data definition has no type or storage class /usr/include/sys/_types.h:33: parse error before '}' token /usr/include/sys/_types.h:33: warning: data definition has no type or storage class In file included from /usr/include/stdio.h:45, from /cygdrive/e/bug/types/test.c:1: . . . . {lots of error messages} ~~~~~~~~~~~~~~~~~~~~~~~~~~~/ | The first error turns out to be that wint_t is not getting defined. | On analyzing the gcc preprocessed file, it is found that wint_t is defined | in stddef.h which for some reason, splint is not including while preprocessing. /~~~~~~~~~~~~~~~~~~~~~~~~~~~ [joy ~/bug/types ]$gcc -E test.c > gcc-full.c ~~~~~~~~~~~~~~~~~~~~~~~~~~~/ | gcc-full.c /~~~~~~~~~~~~~~~~~~~~~~~~~~~ 57 # 1 "/usr/lib/gcc-lib/i686-pc-cygwin/3.2/include/stddef.h" 1 3 58 # 323 "/usr/lib/gcc-lib/i686-pc-cygwin/3.2/include/stddef.h" 3 59 typedef unsigned int wint_t; 60 # 23 "/usr/include/sys/_types.h" 2 3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~/ | Try including the file with an explicit -I directive. /~~~~~~~~~~~~~~~~~~~~~~~~~~~ [joy ~/bug/types ]$splint -nolib test.c -I /usr/lib/gcc-lib/i686-pc-cygwin/3.2/include Splint 3.1.1 --- 02 May 2003 /usr/lib/gcc-lib/i686-pc-cygwin/3.2/include/stdarg.h:44:41: Parse Error: Suspect missing struct or union keyword: __builtin_va_list : unsigned long int. (For help on parse errors, see splint -help parseerrors.) *** Cannot continue. ~~~~~~~~~~~~~~~~~~~~~~~~~~~/ | Splint gives a different error now, and this error is valid. __builtin_va_list | is not defined in the gcc-full.c (gcc preprocessed file) also. It seems to be | some gcc specific `built-in` symbol. Again on running splint with -D__builtin_va_list=int /~~~~~~~~~~~~~~~~~~~~~~~~~~~ [joy ~/bug/types ]$splint -nolib test.c -I /usr/lib/gcc-lib/i686-pc-cygwin/3.2/include -D__builtin_va_list=int Splint 3.1.1 --- 02 May 2003 Finished checking --- no warnings ~~~~~~~~~~~~~~~~~~~~~~~~~~~/ | Thus, | 1. Splint for some reason doesn not include the stddef.h file, while preprocessing | the test file. And does not report any warning or error message that it has | not included it. It does include them when given with an explicit -I directive. | 2. The symbol __builtin_va_list is not defined in the gcc-full.c flag. And yet | gcc parses through it. Why?Is splint is correct in reporting that error. | Coming back to the pthreads problem. The following is the code which Dave | had sent. /~~~~~~~~~~~~~~~~~~~~~~~~~~~ [joy ~/bug ]$cat debug.c #include static pthread_mutex_t mutex; /* Create */ int init(void) { int status; /* mutex */ status = pthread_mutex_init(&mutex, NULL); return status; } /* Destroy */ int destroy(void) { int status; /* mutex */ status = pthread_mutex_destroy(&mutex); return status; } int main(void) { return 0; } ~~~~~~~~~~~~~~~~~~~~~~~~~~~/ | Get sorted list of included header files. | Note that splint-full.c is the splint preprocessed file obtained | by using the +keep option. /~~~~~~~~~~~~~~~~~~~~~~~~~~~ [joy ~/bug ]$gcc -E debug.c > gcc-full.c [joy ~/bug ]$grep "\.h" splint-full.c | cut -d" " -f3 | uniq | sort > splint-headers [joy ~/bug ]$grep "\.h" gcc-full.c | cut -d" " -f3 | uniq | sort > gcc-headers [joy ~/bug ]$diff splint-headers gcc-headers 3a4,7 > "/usr/include/cygwin/config.h" > "/usr/include/cygwin/types.h" > "/usr/include/cygwin/types.h" > "/usr/include/cygwin/types.h" 4a9 > "/usr/include/machine/time.h" 10a16,20 > "/usr/include/sched.h" > "/usr/include/sched.h" > "/usr/include/signal.h" > "/usr/include/signal.h" > "/usr/include/stdint.h" 14a25 > "/usr/include/sys/config.h" 16,19c27 < "/usr/include/sys/sched.h" < "/usr/include/sys/sched.h" < "/usr/include/sys/sched.h" < "/usr/include/sys/signal.h" --- > "/usr/include/sys/reent.h" 21c29,31 < "/usr/include/sys/time.h" --- > "/usr/include/sys/sysmacros.h" > "/usr/include/sys/types.h" > "/usr/include/sys/types.h" 27,28c37,40 < "/usr/include/sys/unistd.h" < "/usr/include/sys/unistd.h" --- > "/usr/include/time.h" > "/usr/include/time.h" > "/usr/include/time.h" > "/usr/include/time.h" ~~~~~~~~~~~~~~~~~~~~~~~~~~~/ | It is seen that splint does not include a few header files which gcc includes, | and that is creating the problem. | In this case pthread_t and pthread_attr_t are not defined in the splint preprocessed | file. These are present in /usr/include/cygwin/types.h which is not getting | #include'd by splint. | Is this a problem with splint or gcc ? Splint 3.1.1 --- 02 May 2003 on Cygwin version 2.340.2.5. Saravana **************************************************************************************** Note: The information contained in this message may be privileged and confidential and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. **************************************************************************************** From mc.howe at virgin.net Mon Apr 26 10:00:44 2004 From: mc.howe at virgin.net (Martin Howe) Date: Wed Mar 22 17:10:30 2006 Subject: [splint-discuss] Annotating **something Message-ID: <005501c42b96$e0c14db0$4d590352@AJP8880> I have a function that acts, for now, as a wrapper for free(): bool_t MEMDelete (/*@special@*/ void **ptr) /*@requires notnull ptr,*ptr@*/ /*@releases *ptr@*/ /*@ensures isnull *ptr@*/ { free(*ptr); *ptr=NULL; return TRUE; } Because of the double indirection I am having to use the SPECIAL annotation and state clauses. The problem is that SPLINT doesn't know that the pointer to which ptr points (i.e. *ptr) is an ONLY reference and there appears no way to annotate this from within a state clause. In the overall context of my application, kludging it with a typedef (e.g., typedef /*@only@*/ void *onlyvoidstar;) is not acceptable; surely there is an "official" way of dealing with something like this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20040426/f912b815/attachment.htm From evans at cs.virginia.edu Mon Apr 26 10:23:18 2004 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:10:30 2006 Subject: [splint-discuss] Annotating **something In-Reply-To: <005501c42b96$e0c14db0$4d590352@AJP8880> References: <005501c42b96$e0c14db0$4d590352@AJP8880> Message-ID: Martin, I think what you want is, /*@requires only *ptr@*/ See section 7.5 of the Splint manual for details. --- Dave On Mon, 26 Apr 2004, Martin Howe wrote: > I have a function that acts, for now, as a wrapper for free(): > > bool_t MEMDelete (/*@special@*/ void **ptr) > /*@requires notnull ptr,*ptr@*/ > /*@releases *ptr@*/ > /*@ensures isnull *ptr@*/ > { > free(*ptr); > *ptr=NULL; > return TRUE; > } > > Because of the double indirection I am having to use the SPECIAL > annotation and state clauses. The problem is that SPLINT doesn't know > that the pointer to which ptr points (i.e. *ptr) is an ONLY reference > and there appears no way to annotate this from within a state clause. > In the overall context of my application, kludging it with a typedef > (e.g., typedef /*@only@*/ void *onlyvoidstar;) is not acceptable; > surely there is an "official" way of dealing with something like this? From stephane.martin at ca.kontron.com Mon Apr 26 10:44:36 2004 From: stephane.martin at ca.kontron.com (Martin, Stephane) Date: Wed Mar 22 17:10:30 2006 Subject: [splint-discuss] problem with numabstract Message-ID: <5009AD9521A8D41198EE00805F85F18F052572CE@sembo111.teknor.com> Hi, Is there anyone that have experienced the new Splint directive numabstract. I use a dot rc config file where I have added the following directive: +numabstractlit +numabstractindex -numabstractcast I also use a common define.h file where a have created abstracted type: typedef /*@numabstract@*/ unsigned char unsigned_int8; typedef /*@numabstract@*/ char int8; Finally I use the main file with the following Splint directive: /* Splint Directives that must be after define.h */ /*@access unsigned_int8@*/ /*@access int8@*/ void main(void) { unsigned_int8 position,checksum,length; unsigned_int8 rawBuffer[10] = {0,1,2,3,4,5,6,7,8,9}; length = 10; for(position=0,checksum=0;position, etc.) can be used on it That does not seems to apply in my case!!!! :\Travail\Soleil\FWUM\src\FWUM.c(24,48): Operand of ++ is non-numeric (unsigned_int8): position ------------------------------------------------------------- Stephane Martin, ing. Kontron Canada Low Level Software Engineer 616 Cure-Boivin Tel (450) 437-4661 ext: 2349 Boisbriand, Quebec Fax (450) 437-8053 Canada, J7G 2A7 mailto:stephane.martin@ca.kontron.com http://www.kontron.com From mc.howe at virgin.net Mon Apr 26 10:49:35 2004 From: mc.howe at virgin.net (Martin Howe) Date: Wed Mar 22 17:10:30 2006 Subject: [splint-discuss] Annotating **something References: <005501c42b96$e0c14db0$4d590352@AJP8880> Message-ID: <006301c42b9d$b1dc2130$4d590352@AJP8880> ----- Original Message ----- From: "David Evans" To: Sent: Monday, April 26, 2004 3:23 PM Subject: Re: [splint-discuss] Annotating **something > I think what you want is, > > /*@requires only *ptr@*/ David, Thanks; unfortunately I had in fact already tried that, with no effect :-( For the record, the error is: services.c:96:7: Unqualified storage *ptr passed as only param: free (*ptr) Unqualified storage is transferred in an inconsistent way. (Use -unqualifiedtrans to inhibit warning) From mc.howe at virgin.net Mon Apr 26 14:58:52 2004 From: mc.howe at virgin.net (Martin Howe) Date: Wed Mar 22 17:10:30 2006 Subject: [splint-discuss] Annotating **something References: <005501c42b96$e0c14db0$4d590352@AJP8880> <006301c42b9d$b1dc2130$4d590352@AJP8880> Message-ID: <000b01c42bc0$852e5d60$4d590352@AJP8880> I have also found this: char *mystring=NULL; void func(/*@special@*/ void **outstring) /*@requires notnull outstring@*/ /*@requires isnull *outstring@*/ /*@ensures notnull *outstring@*/ { *outstring=malloc(30); if (*outstring==NULL) { exit(1); } } func(&mystring); This should be simple. It tells SPLINT that (*outstring) must be NULL when the function is called and that the function is guaranteed to set it to non-null when it returns. There is a check to ensure that outstring did indeed get storage allocated to it and is not null -- if this does not happen, the function exits the program entirely However, this provokes SPLINT to state that storage *outstring may become null, followed by an a statement that it DOES become null -- the line number of this latter warning is the "isnull" annotation!! Surely if a function changes the null state of a variable, it MUST have the annotations like that?? ((since that is the whole point of what the function does))?? From michael.winkler at lvf.liebherr.com Fri Apr 30 05:22:49 2004 From: michael.winkler at lvf.liebherr.com (Winkler Michael (LVF)) Date: Wed Mar 22 17:10:30 2006 Subject: [splint-discuss] No standard Flag settings Message-ID: <50750E91AE69D3118A5E0000E85F01AA027B945E@LVF-MAIL> I use Splint 3.1.1 under Windows and I suspect that in a configuration file there are the standard flag settings. I want to have no standard Flag settings and make all (really all 485) Flag settings in an options file. I must inhibt the warnings like "Setting +zeroptr redundant with current value". I have no idea, but its very important for me, please help! Mit freundlichen Gr??en Michael Winkler LIEBHERR-TRANSPORTATION SYSTEMS GmbH Austria / 2100 Korneuburg / Liebherrstrasse 1 +43 (0) 2262 602-364 +43 (0) 2262 602-503 (FAX) michael.winkler@lvf.liebherr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20040430/5f880031/attachment.htm From stephane.martin at ca.kontron.com Fri Apr 30 08:30:56 2004 From: stephane.martin at ca.kontron.com (Martin, Stephane) Date: Wed Mar 22 17:10:30 2006 Subject: [splint-discuss] No standard Flag settings Message-ID: <5009AD9521A8D41198EE00805F85F18F052D6245@sembo111.teknor.com> just call splint with -f and your dot rc file where you can enable/disabe all checks: splint -f %2\lintrc\lclint.rc %SPLIFILE% ------------------------------------------------------------- Stephane Martin, ing. Kontron Canada Low Level Software Engineer 616 Cure-Boivin Tel (450) 437-4661 ext: 2349 Boisbriand, Quebec Fax (450) 437-8053 Canada, J7G 2A7 mailto:stephane.martin@ca.kontron.com http://www.kontron.com > -----Original Message----- > From: Winkler Michael (LVF) [SMTP:michael.winkler@lvf.liebherr.com] > Sent: 30 avril, 2004 05:23 > To: splint-discuss@cs.virginia.edu > Subject: [splint-discuss] No standard Flag settings > > I use Splint 3.1.1 under Windows and I suspect that in a configuration > file there are the standard flag settings. I want to have no standard Flag > settings and make all (really all 485) Flag settings in an options file. I > must inhibt the warnings like "Setting +zeroptr redundant with current > value". I have no idea, but its very important for me, please help! > > > Mit freundlichen Gr??en > > Michael Winkler > > LIEBHERR-TRANSPORTATION SYSTEMS GmbH > > Austria / 2100 Korneuburg / Liebherrstrasse 1 > > +43 (0) 2262 602-364 > > +43 (0) 2262 602-503 (FAX) > > michael.winkler@lvf.liebherr.com > > > > << File: ATT141435.txt >> From evans at cs.virginia.edu Fri Apr 30 08:50:39 2004 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:10:30 2006 Subject: [splint-discuss] No standard Flag settings In-Reply-To: <5009AD9521A8D41198EE00805F85F18F052D6245@sembo111.teknor.com> References: <5009AD9521A8D41198EE00805F85F18F052D6245@sembo111.teknor.com> Message-ID: If you use -warnflags splint will not produce the "Setting flag redundant with current value" messages. You need to put the -warnflags first, like this: splint -warnflags -f +warnflags (or put the -warnflags inside your .splintrc file). --- Dave > > -----Original Message----- > > From: Winkler Michael (LVF) [SMTP:michael.winkler@lvf.liebherr.com] > > Sent: 30 avril, 2004 05:23 > > To: splint-discuss@cs.virginia.edu > > Subject: [splint-discuss] No standard Flag settings > > > > I use Splint 3.1.1 under Windows and I suspect that in a configuration > > file there are the standard flag settings. I want to have no standard Flag > > settings and make all (really all 485) Flag settings in an options file. I > > must inhibt the warnings like "Setting +zeroptr redundant with current > > value". I have no idea, but its very important for me, please help! From michael.winkler at lvf.liebherr.com Fri Apr 30 07:16:22 2004 From: michael.winkler at lvf.liebherr.com (Winkler Michael (LVF)) Date: Wed Mar 22 17:10:31 2006 Subject: [splint-discuss] FAQ #15 Message-ID: <50750E91AE69D3118A5E0000E85F01AA027B9460@LVF-MAIL> line in options file: +DINT8U=unsigned char Splint don't like the the space between unsigned and char. Are "unsigned char" and "unsignedchar" the same (maybe for Splint)??? What should I do??? Mit freundlichen Gr??en Michael Winkler LIEBHERR-TRANSPORTATION SYSTEMS GmbH Austria / 2100 Korneuburg / Liebherrstrasse 1 +43 (0) 2262 602-364 +43 (0) 2262 602-503 (FAX) michael.winkler@lvf.liebherr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20040430/1f59e8e6/attachment.htm