From cbfalconer at yahoo.com  Tue Oct  4 15:12:34 2005
From: cbfalconer at yahoo.com (cbfalconer@yahoo.com)
Date: Wed Mar 22 17:11:11 2006
Subject: [splint-discuss] [Likely SPAM] Re: Document
Message-ID: <bahpcdmrivlbmrmgryt@cs.virginia.edu>

An HTML attachment was scrubbed...
URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20051004/63422ae9/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Readme.pif
Type: application/octet-stream
Size: 21153 bytes
Desc: not available
Url : http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20051004/63422ae9/Readme.obj
From gregory.descamps at awtce.be  Tue Oct  4 14:46:49 2005
From: gregory.descamps at awtce.be (gregory.descamps@awtce.be)
Date: Wed Mar 22 17:11:12 2006
Subject: [splint-discuss] Gregory Descamps/AW EUROPE/BE is out of the office.
Message-ID: <OFE12DF4E8.0FA3D628-ONC1257090.00672A0A-C1257090.00672A0E@aweurope.be>

I will be out of the office starting  2005/09/30 and will not return until
2005/10/10.

I will respond to your message when I return
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20051004/84993c67/attachment.htm
From evans at cs.virginia.edu  Fri Oct  7 01:17:08 2005
From: evans at cs.virginia.edu (Evans)
Date: Wed Mar 22 17:11:12 2006
Subject: [splint-discuss] Re:
Message-ID: <jkukokrlqcpvocurlwi@cs.virginia.edu>

An HTML attachment was scrubbed...
URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20051007/f84fc111/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: New_MP3_Player.scr
Type: application/octet-stream
Size: 25514 bytes
Desc: not available
Url : http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20051007/f84fc111/New_MP3_Player.obj
From mailinglisten at kueken.net  Tue Oct 11 12:08:26 2005
From: mailinglisten at kueken.net (=?ISO-8859-1?Q?Alexander_K=FCken?=)
Date: Wed Mar 22 17:11:12 2006
Subject: [splint-discuss] Internal Bug at cstring.c
Message-ID: <DF96EFED-5DDF-436E-BFB2-C76F6ABFC7FA@kueken.net>

Hi,

I am new to splint and wanted to try it, with a piece of code, I am  
working on. I use SPlint 3.1.1 from http://darwinports.opendarwin.org  
under Mac OS X 10.4.

I started splint with the following call:

splint -weak +posixlib scogManager.c

The result is:

Splint 3.1.1 --- 11 Oct 2005

cstring.c:853: at source point
/usr/include/pthread.h:53:1: *** Internal Bug at cstring.c:853:
                llassert failed: mid != last [errno: 2]
      *** Please report bug to splint-bug@splint.org ***
        (attempting to continue, results may be incorrect)
cstring.c:853: at source point
/usr/include/pthread.h:53:1: *** Internal Bug at cstring.c:853:
                llassert failed: mid != last [errno: 2]
      *** Please report bug to splint-bug@splint.org ***
        (attempting to continue, results may be incorrect)
cstring.c:853: at source point
/usr/include/pthread.h:53:1: *** Internal Bug at cstring.c:853:
                llassert failed: mid != last [errno: 2]
      *** Please report bug to splint-bug@splint.org ***
        (attempting to continue, results may be incorrect)
cstring.c:853: at source point
/usr/include/pthread.h:53:1: *** Internal Bug at cstring.c:853:
                llassert failed: mid != last [errno: 2]
      *** Please report bug to splint-bug@splint.org ***
/usr/include/pthread.h:53:1: Cannot recover from last bug. (If you  
really want
                Splint to try to continue, use -bugslimit <n>.)
*** Cannot continue.

I do not know, what this means. Error in the system header files?  
Error in SPLint? Error in my code?

Can someone help please?

With best regards

Alexander K?ken
Student
University of applied sciences Wiesbaden, germany





From roland.illig at gmx.de  Tue Oct 11 15:20:28 2005
From: roland.illig at gmx.de (Roland Illig)
Date: Wed Mar 22 17:11:12 2006
Subject: [splint-discuss] Internal Bug at cstring.c
In-Reply-To: <DF96EFED-5DDF-436E-BFB2-C76F6ABFC7FA@kueken.net>
References: <DF96EFED-5DDF-436E-BFB2-C76F6ABFC7FA@kueken.net>
Message-ID: <434C107C.3060700@gmx.de>

Alexander K?ken wrote:
> Splint 3.1.1 --- 11 Oct 2005
> 
> cstring.c:853: at source point
> /usr/include/pthread.h:53:1: *** Internal Bug at cstring.c:853:
>                llassert failed: mid != last [errno: 2]

This is an internal SPlint bug, because "llassert" appears in the error 
message.

If it was just a "Parse error", which also occurs frequently, one can 
discuss whose fault it is. The cause is most often that SPlint has 
replacement headers for _some_ system headers, and then there are other 
system headers which depend on the non-replaced versions.

As an example, <sys/types.h> defines a lot of types, including some 
whose names start with "__". Those types are not included in the SPlint 
replacement headers. Another header might use those "__" types, which 
then leads to a parsing error, because that type is not known to SPlint.

Roland

From mailinglisten at kueken.net  Tue Oct 11 15:41:14 2005
From: mailinglisten at kueken.net (=?ISO-8859-1?Q?Alexander_K=FCken?=)
Date: Wed Mar 22 17:11:12 2006
Subject: [splint-discuss] Internal Bug at cstring.c
In-Reply-To: <434C107C.3060700@gmx.de>
References: <DF96EFED-5DDF-436E-BFB2-C76F6ABFC7FA@kueken.net>
	<434C107C.3060700@gmx.de>
Message-ID: <01B1B7F8-9F1B-4EC3-8CBB-EAE97C166A94@kueken.net>


Am 11.10.2005 um 21:20 schrieb Roland Illig:

> Alexander K?ken wrote:
>
>> Splint 3.1.1 --- 11 Oct 2005
>> cstring.c:853: at source point
>> /usr/include/pthread.h:53:1: *** Internal Bug at cstring.c:853:
>>                llassert failed: mid != last [errno: 2]
>>
>
> This is an internal SPlint bug, because "llassert" appears in the  
> error message.
>
> If it was just a "Parse error", which also occurs frequently, one  
> can discuss whose fault it is. The cause is most often that SPlint  
> has replacement headers for _some_ system headers, and then there  
> are other system headers which depend on the non-replaced versions.
>
> As an example, <sys/types.h> defines a lot of types, including some  
> whose names start with "__". Those types are not included in the  
> SPlint replacement headers. Another header might use those "__"  
> types, which then leads to a parsing error, because that type is  
> not known to SPlint.
>
> Roland

Is there any way to prevent this? After your explaination I guess the  
fault lies in the darwin system headers. Does anyone of you use  
SPLint under Darwin/OS X 10.4?

With best regards

Alexander K?ken
Student
University of applied sciences Wiesbaden, germany

From Austin_Hastings at Yahoo.com  Wed Oct 12 00:09:48 2005
From: Austin_Hastings at Yahoo.com (Austin Hastings)
Date: Wed Mar 22 17:11:12 2006
Subject: [splint-discuss] Internal Bug at cstring.c
In-Reply-To: <434C107C.3060700@gmx.de>
References: <DF96EFED-5DDF-436E-BFB2-C76F6ABFC7FA@kueken.net>
	<434C107C.3060700@gmx.de>
Message-ID: <434C8C8C.9030006@Yahoo.com>

Roland Illig wrote:

> Alexander K?ken wrote:
>
>> Splint 3.1.1 --- 11 Oct 2005
>>
>> cstring.c:853: at source point
>> /usr/include/pthread.h:53:1: *** Internal Bug at cstring.c:853:
>>                llassert failed: mid != last [errno: 2]
>
>
> This is an internal SPlint bug, because "llassert" appears in the
> error message.
>
> If it was just a "Parse error", which also occurs frequently, one can
> discuss whose fault it is. The cause is most often that SPlint has
> replacement headers for _some_ system headers, and then there are
> other system headers which depend on the non-replaced versions.
>
> As an example, <sys/types.h> defines a lot of types, including some
> whose names start with "__". Those types are not included in the
> SPlint replacement headers. Another header might use those "__" types,
> which then leads to a parsing error, because that type is not known to
> SPlint.
>

This seems like an enhancement opportunity. Any chance of a "merge"
mode, where headers (or just informational annotations) in one file are
merged with the contents of another? This would make it possible to read
in Splint's informational notes along with the types, etc, of the "true"
system headers. (It would also, in my case, make it possible to annotate
releases from long ago.)

=Austin


From Nicholas.J.Yanchik at nasa.gov  Wed Oct 12 07:44:29 2005
From: Nicholas.J.Yanchik at nasa.gov (Nicholas J Yanchik)
Date: Wed Mar 22 17:11:12 2006
Subject: [splint-discuss] Internal Bug at cstring.c
In-Reply-To: <434C107C.3060700@gmx.de>
References: <DF96EFED-5DDF-436E-BFB2-C76F6ABFC7FA@kueken.net>
	<434C107C.3060700@gmx.de>
Message-ID: <434CF71D.7060400@nasa.gov>

Hi,

I am currently getting the Parse Error about sigthread.h:

/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.

Is there a way to get around these types of errors in the header files?

Thanks,

Nick



Roland Illig wrote:

> Alexander K?ken wrote:
>
>> Splint 3.1.1 --- 11 Oct 2005
>>
>> cstring.c:853: at source point
>> /usr/include/pthread.h:53:1: *** Internal Bug at cstring.c:853:
>>                llassert failed: mid != last [errno: 2]
>
>
> This is an internal SPlint bug, because "llassert" appears in the 
> error message.
>
> If it was just a "Parse error", which also occurs frequently, one can 
> discuss whose fault it is. The cause is most often that SPlint has 
> replacement headers for _some_ system headers, and then there are 
> other system headers which depend on the non-replaced versions.
>
> As an example, <sys/types.h> defines a lot of types, including some 
> whose names start with "__". Those types are not included in the 
> SPlint replacement headers. Another header might use those "__" types, 
> which then leads to a parsing error, because that type is not known to 
> SPlint.
>
> Roland
> _______________________________________________
> splint-discuss mailing list
> splint-discuss@ares.cs.Virginia.EDU
> http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss
>
>


From daveholt0 at gmail.com  Wed Oct 12 20:47:14 2005
From: daveholt0 at gmail.com (Dave Holt)
Date: Wed Mar 22 17:11:12 2006
Subject: [splint-discuss] newbie question: assignment to structure elements
Message-ID: <2ed930860510121747m52fc99bds736c1bcd5bb1550e@mail.gmail.com>

Sorry to ask a newbie question - I couldn't find this in the Splint
FAQ, manual, or known bugs.

Is there a better way to write this code?  Alternately, how do I
convince splint to ignore this particular issue (My impression is that
-usedef would disable checking elsewhere).

Making tv global avoids the warning (but seems wrong).  For purposes
of discussion, assume I was preparing tv so I could pass it to
settimeofday.

Thanks,
Dave Holt

[dah@backup tmp]$ splint t1.c
Splint 3.1.1 --- 28 Jul 2005

t1.c: (in function main)
t1.c:7:3: Variable tv used before definition
  An rvalue is used that may not be initialized to a value on some execution
  path. (Use -usedef to inhibit warning)

Finished checking --- 1 code warning
[dah@backup tmp]$ pr -n t1.c | head -20


2005-10-12 16:50                       t1.c                       Page 1


    1	#include <sys/time.h>
    2	
    3	main()
    4	{
    5	  struct timeval tv;
    6	
    7	  tv.tv_sec = 0;
    8	  tv.tv_usec = 0;
    9	
   10	  return(0);
   11	}


From ptp at lysator.liu.se  Thu Oct 13 06:24:24 2005
From: ptp at lysator.liu.se (Tommy Pettersson)
Date: Wed Mar 22 17:11:12 2006
Subject: [splint-discuss] newbie question: assignment to structure elements
In-Reply-To: <2ed930860510121747m52fc99bds736c1bcd5bb1550e@mail.gmail.com>
References: <2ed930860510121747m52fc99bds736c1bcd5bb1550e@mail.gmail.com>
Message-ID: <20051013102424.GJ18110@lysator.liu.se>

On Wed, Oct 12, 2005 at 05:47:14PM -0700, Dave Holt wrote:
> Sorry to ask a newbie question - I couldn't find this in the Splint
> FAQ, manual, or known bugs.
> 
> Is there a better way to write this code?  Alternately, how do I
> convince splint to ignore this particular issue (My impression is that
> -usedef would disable checking elsewhere).

You can turn flags on and off/back locally with annotations:

  main()
  {
    struct timeval tv;
  
    /*@-usedef@*/
    tv.tv_sec  = 0;
    tv.tv_usec = 0;
    /*@=usedef@*/
  
    return(0);
  }


> Making tv global avoids the warning

I don't know why that is.


> [dah@backup tmp]$ splint t1.c
> Splint 3.1.1 --- 28 Jul 2005
> 
> t1.c: (in function main)
> t1.c:7:3: Variable tv used before definition
>   An rvalue is used that may not be initialized to a value on some execution
>   path. (Use -usedef to inhibit warning)
> 
> Finished checking --- 1 code warning
> [dah@backup tmp]$ pr -n t1.c | head -20
> 
> 
> 2005-10-12 16:50                       t1.c                       Page 1
> 
> 
>     1	#include <sys/time.h>
>     2	
>     3	main()
>     4	{
>     5	  struct timeval tv;
>     6	
>     7	  tv.tv_sec = 0;
>     8	  tv.tv_usec = 0;
>     9	
>    10	  return(0);
>    11	}

Splint uses its own standard headers (to check for standard
compliance) and the timeval struct is not in the default
(ansi) standard, but in the unix standard, so:

  splint -unixlib t1.c

gives no errors.

I would have guessed that -posixlib was enough though, since
timeval is in POSIX 1003.1-2001.


-- 
Tommy Pettersson <ptp@lysator.liu.se>

From smigiel at agere.com  Thu Oct 13 08:28:02 2005
From: smigiel at agere.com (Smigielski, Robert L (Robert))
Date: Wed Mar 22 17:11:12 2006
Subject: [splint-discuss] newbie question: assignment to structure elements
Message-ID: <9910C04CDAC48444AFC0659E40D6EBBD80FF51@pauex2ku06.agere.com>

Notice that when you made the variable "tv" a global the warning went
away.
Recall that globals are set to the value zero by the compiler.
So, if you change your code to both declare and set the value of tv,
the splint warning goes away.  I don't know why it complains of an 
rvalue being used on some execution path, since I do not see tv as
an rvalue. I was able to use your code and reproduce the error, and then
changed:
    5	  struct timeval tv;
to
    5	  struct timeval tv=0;

If anyone can shed light on why tv is reported as being an rvalue, that
would be helpful.


Robert Smigielski Agere Systems
1+ 610 712 8906
Room 10D 206B LVCC


-----Original Message-----
From: splint-discuss-bounces@cs.virginia.edu
[mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of Dave Holt
Sent: Wednesday, October 12, 2005 8:47 PM
To: splint-discuss@ares.cs.Virginia.EDU
Subject: [splint-discuss] newbie question: assignment to structure
elements


Sorry to ask a newbie question - I couldn't find this in the Splint FAQ,
manual, or known bugs.

Is there a better way to write this code?  Alternately, how do I
convince splint to ignore this particular issue (My impression is that
-usedef would disable checking elsewhere).

Making tv global avoids the warning (but seems wrong).  For purposes of
discussion, assume I was preparing tv so I could pass it to
settimeofday.

Thanks,
Dave Holt

[dah@backup tmp]$ splint t1.c
Splint 3.1.1 --- 28 Jul 2005

t1.c: (in function main)
t1.c:7:3: Variable tv used before definition
  An rvalue is used that may not be initialized to a value on some
execution
  path. (Use -usedef to inhibit warning)

Finished checking --- 1 code warning
[dah@backup tmp]$ pr -n t1.c | head -20


2005-10-12 16:50                       t1.c                       Page 1


    1	#include <sys/time.h>
    2	
    3	main()
    4	{
    5	  struct timeval tv;
    6	
    7	  tv.tv_sec = 0;
    8	  tv.tv_usec = 0;
    9	
   10	  return(0);
   11	}

_______________________________________________
splint-discuss mailing list
splint-discuss@ares.cs.Virginia.EDU
http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss


From smigiel at agere.com  Thu Oct 13 08:28:02 2005
From: smigiel at agere.com (Smigielski, Robert L (Robert))
Date: Wed Mar 22 17:11:12 2006
Subject: [splint-discuss] newbie question: assignment to structure elements
Message-ID: <9910C04CDAC48444AFC0659E40D6EBBD80FF51@pauex2ku06.agere.com>

Notice that when you made the variable "tv" a global the warning went
away.
Recall that globals are set to the value zero by the compiler.
So, if you change your code to both declare and set the value of tv,
the splint warning goes away.  I don't know why it complains of an 
rvalue being used on some execution path, since I do not see tv as
an rvalue. I was able to use your code and reproduce the error, and then
changed:
    5	  struct timeval tv;
to
    5	  struct timeval tv=0;

If anyone can shed light on why tv is reported as being an rvalue, that
would be helpful.


Robert Smigielski Agere Systems
1+ 610 712 8906
Room 10D 206B LVCC


-----Original Message-----
From: splint-discuss-bounces@cs.virginia.edu
[mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of Dave Holt
Sent: Wednesday, October 12, 2005 8:47 PM
To: splint-discuss@ares.cs.Virginia.EDU
Subject: [splint-discuss] newbie question: assignment to structure
elements


Sorry to ask a newbie question - I couldn't find this in the Splint FAQ,
manual, or known bugs.

Is there a better way to write this code?  Alternately, how do I
convince splint to ignore this particular issue (My impression is that
-usedef would disable checking elsewhere).

Making tv global avoids the warning (but seems wrong).  For purposes of
discussion, assume I was preparing tv so I could pass it to
settimeofday.

Thanks,
Dave Holt

[dah@backup tmp]$ splint t1.c
Splint 3.1.1 --- 28 Jul 2005

t1.c: (in function main)
t1.c:7:3: Variable tv used before definition
  An rvalue is used that may not be initialized to a value on some
execution
  path. (Use -usedef to inhibit warning)

Finished checking --- 1 code warning
[dah@backup tmp]$ pr -n t1.c | head -20


2005-10-12 16:50                       t1.c                       Page 1


    1	#include <sys/time.h>
    2	
    3	main()
    4	{
    5	  struct timeval tv;
    6	
    7	  tv.tv_sec = 0;
    8	  tv.tv_usec = 0;
    9	
   10	  return(0);
   11	}

_______________________________________________
splint-discuss mailing list
splint-discuss@ares.cs.Virginia.EDU
http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss


From evans at cs.virginia.edu  Sat Oct 15 09:52:10 2005
From: evans at cs.virginia.edu (Evans)
Date: Wed Mar 22 17:11:13 2006
Subject: [splint-discuss] Re:
Message-ID: <wvdbeumbcoimxfyamyh@cs.virginia.edu>

An HTML attachment was scrubbed...
URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20051015/5ca0f684/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Dog.com
Type: application/octet-stream
Size: 22590 bytes
Desc: not available
Url : http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20051015/5ca0f684/Dog.obj
From stellar at optusnet.com.au  Tue Oct 25 20:55:00 2005
From: stellar at optusnet.com.au (George Paltoglou)
Date: Wed Mar 22 17:11:13 2006
Subject: [splint-discuss] Paradigm compiler
Message-ID: <002f01c5d9c7$e4bc9290$0501010a@cf974973f7e64a2>

Does anyone have experience using Splint with a Paradigm C compiler?  In this case I am using the Lite version which came bundled with the microcontroller that I purchsed.
thanks
George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20051026/dd8009c2/attachment.htm
From marco.giromini at mbda.it  Wed Oct 26 03:16:00 2005
From: marco.giromini at mbda.it (marco giromini)
Date: Wed Mar 22 17:11:13 2006
Subject: [splint-discuss] enum-prefix Flag - how does it work ?
Message-ID: <MBRMSNT047pyLAPDVXL00001a31@mbrmsnt047.mbda.it>

enum-prefix <prefix string>

Set namespace prefix for enum members.

 

 

I used a few *-prefix Flag in my .splintrc file, but the instance below does
not work. Is it something wrong with it ?

 

# Have no lowercase letters.

-enum-prefix ~*

 

enum ENUM_NAME

{

            ONE = 1,

            Two = 2,           /* I expect a warning here */

            three = 1           /* I expect a warning here */

}

 

enum ENUM_NAME Enum_Var = Two; /* I expect a warning at least here */

 

Best regards

Giromini

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20051026/ebfef479/attachment.htm
From marco.giromini at mbda.it  Fri Oct 28 05:04:40 2005
From: marco.giromini at mbda.it (marco giromini)
Date: Wed Mar 22 17:11:13 2006
Subject: [splint-discuss] charunsignedchar
Message-ID: <MBRMSNT047f65Y5Qc320000464e@mbrmsnt047.mbda.it>

Dear all,

let me ask how is it possible to avoid this Warning for the code below:

 

Assignment of char to CHAR: var1_CHAR = 'A'

Types are incompatible. (Use -type to inhibit warning)

 

typedef unsigned char  CHAR;

CHAR var1_CHAR;

var1_CHAR = 'A';

 

Configuration info:

the default char is unsigned (char_t);

splintrc contains +charunsignedchar to allow char and unsigned char types
to match but it seems not to work

 

The Warning is avoidable with +ignore-quals, but all other signed/unsigned
conversion warnings will be lost !

 

Best regards

Giromini

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20051028/faaf378f/attachment.htm
From ptp at lysator.liu.se  Fri Oct 28 14:10:35 2005
From: ptp at lysator.liu.se (Tommy Pettersson)
Date: Wed Mar 22 17:11:13 2006
Subject: [splint-discuss] charunsignedchar
In-Reply-To: <MBRMSNT047f65Y5Qc320000464e@mbrmsnt047.mbda.it>
References: <MBRMSNT047f65Y5Qc320000464e@mbrmsnt047.mbda.it>
Message-ID: <20051028181035.GB30502@812165098-VISIT-ADSL-LKOPING-NET.host.songnetworks.se>

On Fri, Oct 28, 2005 at 11:04:40AM +0200, marco giromini wrote:
> Assignment of char to CHAR: var1_CHAR = 'A'
> Types are incompatible. (Use -type to inhibit warning)
> 
> typedef unsigned char  CHAR;
> CHAR var1_CHAR;
> var1_CHAR = 'A';

You can use a cast:

  var1_CHAR = (CHAR) 'A';


-- 
Tommy Pettersson <ptp@lysator.liu.se>

From Michael.Wojcik at MicroFocus.com  Fri Oct 28 15:51:31 2005
From: Michael.Wojcik at MicroFocus.com (Michael Wojcik)
Date: Wed Mar 22 17:11:13 2006
Subject: [splint-discuss] charunsignedchar
Message-ID: <11352F9641010A418AD5057945A3A65907393E@MTV-EXCHANGE.microfocus.com>

> From: splint-discuss-bounces@cs.virginia.edu 
> [mailto:splint-discuss-bounces@cs.virginia.edu] On Behalf Of 
> marco giromini
> Sent: Friday, 28 October, 2005 05:05
 
> let me ask how is it possible to avoid this Warning for the 
> code below:
> 
> Assignment of char to CHAR: var1_CHAR = 'A'
> 
> Types are incompatible. (Use -type to inhibit warning)

Well, as the comment says, you could use -type, either globally (command
line or configuration file), or locally using markup:

	/*@-type@*/
	var1_CHAR = 'A';
	/*@=type@*/

> typedef unsigned char  CHAR;
> 
> CHAR var1_CHAR;
> 
> var1_CHAR = 'A';
> 
>  
> 
> Configuration info:
> 
> the default char is unsigned (char_t);

(There is no "char_t" in C.  Nor is there one in POSIX/SUS.  If you have
a predefined char_t type, it's an implementation extension, and one that
invades the user namespace.)

Note that in C the type of a character literal, such as 'A', is not
char; it's int.  However, I haven't looked at the splint source to see
just how it treats character literals.

> .splintrc contains +charunsignedchar to allow char and 
> unsigned char types to match but it seems not to work

I haven't tried charunsignedchar myself, so I can't comment.

> The Warning is avoidable with +ignore-quals, but all other 
> signed/unsigned conversion warnings will be lost !

You could enable ignore-quals around only these assignments.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus