"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 : >>>> <any>. (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 ([EMAIL PROTECTED]) ([EMAIL PROTECTED]) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address! _______________________________________________ splint-discuss mailing list [EMAIL PROTECTED] http://www.splint.org/mailman/listinfo/splint-discuss
