From michael.winkler at lvf.liebherr.com Mon May 3 11:20:42 2004 From: michael.winkler at lvf.liebherr.com (Winkler Michael (LVF)) Date: Wed Mar 22 17:10:31 2006 Subject: [splint-discuss] Splint Pronunciation Message-ID: <50750E91AE69D3118A5E0000E85F01AA027B9468@LVF-MAIL> How is Splint pronounced??? S P Lint or really Splint??? 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/20040503/aef6efa8/attachment.htm From evans at cs.virginia.edu Mon May 3 13:01:05 2004 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:10:31 2006 Subject: [splint-discuss] Splint Pronunciation In-Reply-To: <50750E91AE69D3118A5E0000E85F01AA027B9468@LVF-MAIL> References: <50750E91AE69D3118A5E0000E85F01AA027B9468@LVF-MAIL> Message-ID: I pronounce it "splint" (all one word, like the first aid device used to protect broken bones). "S" "P" "lint" is fine too, but harder to say. --- Dave On Mon, 3 May 2004, Winkler Michael (LVF) wrote: > How is Splint pronounced??? > S P Lint or really Splint??? > > > 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 > > > > > From michael.winkler at lvf.liebherr.com Tue May 4 09:34:52 2004 From: michael.winkler at lvf.liebherr.com (Winkler Michael (LVF)) Date: Wed Mar 22 17:10:31 2006 Subject: [splint-discuss] (void *) Message-ID: <50750E91AE69D3118A5E0000E85F01AA027B946D@LVF-MAIL> Line in Source Code: (void *)pIIC = (void *)strPS.cBuf; Splint detects a parse error with (void *) and I don't want to surround it with # ifndef S_SPLINT_S (void *)pIIC = (void *)strPS.cBuf; # else pIIC = strPS.cBuf; # endif "+D(void *)=" don't work. Is there a smarter way to handle it??? 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/20040504/7ed3e3e5/attachment.htm From roland.illig at gmx.de Tue May 4 16:13:40 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed Mar 22 17:10:32 2006 Subject: [splint-discuss] (void *) In-Reply-To: <50750E91AE69D3118A5E0000E85F01AA027B946D@LVF-MAIL> References: <50750E91AE69D3118A5E0000E85F01AA027B946D@LVF-MAIL> Message-ID: <4097F974.1090504@gmx.de> Winkler Michael (LVF) wrote: > > Line in Source Code: > (void *)pIIC = (void *)strPS.cBuf; > Splint detects a parse error with (void *) and I don't want to surround > it with > > # ifndef S_SPLINT_S > (void *)pIIC = (void *)strPS.cBuf; > # else > pIIC = strPS.cBuf; > # endif I think, a type cast converts an lvalue into an rvalue. Because you cannot assign a value to an rvalue, this statement is illegal. Solution: just leave out the left "(void *)". > "+D(void *)=" don't work. Is there a smarter way to handle it??? The "+D" switch defines a _valid_ C identifier to be a macro. "(void *)" is not a valid identifier, so you cannot define it using "+D". Roland From ok at cs.otago.ac.nz Tue May 4 19:54:09 2004 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed Mar 22 17:10:32 2006 Subject: [splint-discuss] (void *) Message-ID: <200405042354.i44Ns9O3106501@atlas.otago.ac.nz> "Winkler Michael \(LVF\)" wrote: Line in Source Code: (void *)pIIC = (void *)strPS.cBuf; Splint detects a parse error with (void *) more precisely, with the first one. Sinister casts have never *ever* been legal C, and they are quite unnecessary. and I don't want to surround it with #ifndef S_SPLINT_S ... Is there a smarter way to handle it??? Yes, rewrite it in legal C once and for all. If pIIC is some kind of object pointer, a simply pIIC = (void *)strPS.cBuf; will do the job; as pointers of type void* were introduced in C89 precisely so that they could be quietly assigned to any object pointer type without further casting. If pIIC is not some kind of object pointer, you may have serious portability problems. There are systems where function pointers and object pointers are not the same size. There is even one famous architecture still in fairly wide use where integers are 32 bits and pointers are 16 bytes. However, if you have typedef ....... (t) ....; t pIIC; then pIIC = (t)strPS.cBuf; should do the job. A (never-legal-in-K&R-or-ISO-C) sinister cast (xxxx)var = expr; is sometimes implemented to have the effect *((xxx *)&(var)) = expr; which *is* legal C, so there is never any necessity to use sinister casts in C. From cbfalconer at yahoo.com Wed May 5 04:57:06 2004 From: cbfalconer at yahoo.com (CBFalconer) Date: Wed Mar 22 17:10:32 2006 Subject: [splint-discuss] (void *) References: <200405042354.i44Ns9O3106501@atlas.otago.ac.nz> Message-ID: <4098AC62.8DDE3E96@yahoo.com> "Richard A. O'Keefe" wrote: > wrote: > >> Line in Source Code: >> (void *)pIIC = (void *)strPS.cBuf; >> >> Splint detects a parse error with (void *) > > more precisely, with the first one. Sinister casts have never > *ever* been legal C, and they are quite unnecessary. > >> and I don't want to surround it with #ifndef S_SPLINT_S ... >> Is there a smarter way to handle it??? > > Yes, rewrite it in legal C once and for all. > > If pIIC is some kind of object pointer, a simply > >> pIIC = (void *)strPS.cBuf; > > will do the job; as pointers of type void* were introduced in C89 > precisely so that they could be quietly assigned to any object > pointer type without further casting. You should also think about what you are casting. To me, and many others, the precedence is unclear. If you really mean: pIIC = (void*)(strPS).cBuf; you have an illegal statement, since a void* cannot have a field. On the other hand, if you mean: pIIC = (void*)(strPS.cBuf); you probably have an unnecessary or useless cast, since if pIIC is of type void* the cast is unnecessary, and if not the cast leads to possible errors, as there is no guarantee that any pointer other than the original type can be recovered from a void*. The OP could have better included the definition of the strPS structure and cleared this up. At a guess the cBuf field is declared as a char array, with a fixed size, as in: struct foo { ..... char cBuf[BUFSIZE]; ..... } strPS; in which case pIIC is probably declared as char *, and the whole original sequence is the throes of escaping the error signals from the compiler. In this case the statement should have been: pIIC = &(strPS.cBuf); without any casts whatsoever. Casts are inherently evil, and usually indicate some sort of muddled thinking and hidden errors. The OP also posted this as some mixture of html and attachments, which would normally have been simply deleted here. It was only legible as the quote in Mr O'Keefes article. Usenet and e-mail is a plain text medium, anything else is subject to misuse. So only use such things where you have agreement with the destination as to its use. -- fix (vb.): 1. to paper over, obscure, hide from public view; 2. to work around, in a way that produces unintended consequences that are worse than the original problem. Usage: "Windows ME fixes many of the shortcomings of Windows 98 SE". - Hutchison From stevew at icpdd.neca.nec.com.au Sun May 9 19:24:59 2004 From: stevew at icpdd.neca.nec.com.au (Steven Walker) Date: Wed Mar 22 17:10:32 2006 Subject: [splint-discuss] Palm OS System calls Message-ID: <001701c4361c$d8984ae0$f1944c93@trinity> Hi All, I am trying to determine if a solution to the problem below was ever determined ? If so could it be broadcast please. Thanks and Regards, Steve Walker Tom Link splint-discuss@cs.virginia.edu Fri, 05 Dec 2003 16:29:16 -0500 * Previous message: [splint-discuss] Build error on HP-UX * Next message: [splint-discuss] Problem with #include * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] _____ I am trying to use splint with PalmOS source code, but one of the Palm header files causes problems I cannot seem to get around. PalmOS System calls (and other shared library calls) are implemented with functions declared using the syntax: Retval SomeFunction(parameters ....) SYS_TRAP(trapnum); It seems that the SYS_TRAP macro at the end causes: Parse Error: New function scope inside function. Does anyone have a suggestion on a bypass for this? Tom Link -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20040510/6f8e7105/attachment.htm From michael.winkler at lvf.liebherr.com Mon May 10 03:58:45 2004 From: michael.winkler at lvf.liebherr.com (Winkler Michael (LVF)) Date: Wed Mar 22 17:10:32 2006 Subject: [splint-discuss] Memory on an Embedded System Message-ID: <50750E91AE69D3118A5E0000E85F01AA027B9476@LVF-MAIL> I develop C Source Code for Embedded Systems. Could I teach Splint the memory bounds of the Embedded System to have a better use of the Memory Management Flags??? 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/20040510/4e82a1b0/attachment.htm From roland.illig at gmx.de Mon May 10 04:04:35 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed Mar 22 17:10:32 2006 Subject: [splint-discuss] Palm OS System calls In-Reply-To: <001701c4361c$d8984ae0$f1944c93@trinity> References: <001701c4361c$d8984ae0$f1944c93@trinity> Message-ID: <409F3793.7040905@gmx.de> Steven Walker wrote: > > Hi All, > > I am trying to determine if a solution to the problem below > was ever determined ? > > Retval SomeFunction(parameters ....) SYS_TRAP(trapnum); > > It seems that the SYS_TRAP macro at the end causes: > > Parse Error: > New function scope inside function. > > Does anyone have a suggestion on a bypass for this? > I tried splint -D"SYS_TRAP(a)=" foo.c and succeeded. Roland From snadathur at internetphotonics.com Mon May 10 14:06:23 2004 From: snadathur at internetphotonics.com (Srivathsan Nadathur) Date: Wed Mar 22 17:10:32 2006 Subject: [splint-discuss] parse error Message-ID: <10C3A30F132FCC4D8630A7C17FBA43F6145007@megamail.internetphotonics.com> How do I get rid of the splint warning that crops up when it touches the linux header file . The offending line is ./asm/types.h:typedef __signed__ char __s8; Looks like the __signed__ is confusing the checker. I have the options -sys-dirs and -sys-unrecog and -sys-dir-errors all enabled. I am cross compiling for an embedded system, so I have my own set of system dirs. Thanks sri. From roland.illig at gmx.de Tue May 11 13:37:12 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed Mar 22 17:10:32 2006 Subject: [splint-discuss] parse error In-Reply-To: <10C3A30F132FCC4D8630A7C17FBA43F6145007@megamail.internetphotonics.com> References: <10C3A30F132FCC4D8630A7C17FBA43F6145007@megamail.internetphotonics.com> Message-ID: <40A10F48.50009@gmx.de> Srivathsan Nadathur wrote: > How do I get rid of the splint warning that crops up when it > touches the linux header file . The offending line is > > ./asm/types.h:typedef __signed__ char __s8; > > Looks like the __signed__ is confusing the checker. I have the options > -sys-dirs and -sys-unrecog and -sys-dir-errors all enabled. I am cross compiling for > an embedded system, so I have my own set of system dirs. $ splint -D__signed__=signed file.c or $ splint -D__signed__= file.c see also http://www.splint.org/faq.html#quest14 Roland From cyril.soldani at wallonieproductions.com Wed May 12 08:47:33 2004 From: cyril.soldani at wallonieproductions.com (Cyril Soldani) Date: Wed Mar 22 17:10:32 2006 Subject: [splint-discuss] inttypes.h support Message-ID: <20040512144733.6f2e5ee5.cyril.soldani@wallonieproductions.com> Hello, I have a parse error in splint if I try to use a macro of the SCNxNN family (e.g. SCNu8). I checked these macros are defined in the ISO C99 standard and it is. However, splint doesn't seem to support them. I tried with the -skipisoheaders flags but it didn't worked (in fact, inttypes.h isn't in the list of ISO headers given by splint -help skipisoheaders). I can remedy the problem with : #ifdef S_SPLINT_S # define SCNu8 "hhu" #endif but it is a bit painful and not very flexible. I tried to add inttypes.h support to standard.h and rebuild standard.lcd but I haven't succeeded. If I use any type but char * (e.g. /*@constant char SCNu8@*/) I get rid of the parse error but type is of course incorrect. And if I use type char * (/*@constant char * SCNu8@*/), the pase error remains. So, - Am I right while thinking splint has no inttypes.h support ? - If it hasn't, is there any good reason ? - How can I add inttypes.h support in splint ? In the same order of idea, I'd like to add support for "%hhu" format string. - Is there something wrong with using this format ? - How can I add it to splint ? Cordially, -- Cyril Soldani Wallonie Productions http://www.wallonieproductions.com info@wallonieproductions.com -------------- 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/20040512/902b6dbe/attachment.bin From michael.winkler at lvf.liebherr.com Thu May 13 10:58:46 2004 From: michael.winkler at lvf.liebherr.com (Winkler Michael (LVF)) Date: Wed Mar 22 17:10:33 2006 Subject: [splint-discuss] Initialization Flags - Order? Message-ID: <50750E91AE69D3118A5E0000E85F01AA027B9487@LVF-MAIL> Is there a correct order of placing initialization flags or is it never mind??? Mit freundlichen Gr??en Michael Winkler Systemtechnik / Elektronik LIEBHERR-TRANSPORTATION SYSTEMS GMBH Liebherrstra?e 1 A-2100 Korneuburg Phone: +43 (0) 2262 602 364 Fax: +43 (0) 2262 602 503 michael.winkler@lvf.liebherr.com www.liebherr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20040513/e807343a/attachment.htm From cyril.soldani at wallonieproductions.com Thu May 13 16:57:57 2004 From: cyril.soldani at wallonieproductions.com (Cyril Soldani) Date: Wed Mar 22 17:10:33 2006 Subject: [splint-discuss] Macros with variable number of arguments Message-ID: <20040513225757.459b2ea4.cyril.soldani@wallonieproductions.com> Hello, Whenever I define a macro with a variable number of arguments following ISO C99 (e.g. #define MACRO(...) some_action), I get these errors : debug.h:25:2: Invalid character in macro parameter name Preprocessing error. (Use -preproc to inhibit warning) debug.h:25:2: Parameter list for #define is not parseable Preprocessing error for file: /home/soldani/cours/tfe/new/debug.h *** Cannot continue. After a bit of Googling, I realised splint doesn't support ISO C99 variable argument macros. Having no idea how to modify this, I wanted to isolate litigious code between /*@-preproc@*/ and /*@+preproc@*/. It didn't worked. I tried just around the wrong line as well as for all file, there was no change. However, if I pass the parameter -preproc to splint, the warnings disappear. Does anybody knows a way to pass ISO C99 macros with variables arguments in splint other than passing the '-preproc' flag ? Regards, -- Cyril Soldani Wallonie Productions http://www.wallonieproductions.com info@wallonieproductions.com -------------- 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/20040513/ba5ae1a6/attachment.bin From dirk at dirk-herrmanns-seiten.de Sat May 15 04:09:10 2004 From: dirk at dirk-herrmanns-seiten.de (Dirk Herrmann) Date: Wed Mar 22 17:10:33 2006 Subject: [splint-discuss] Repeated: Bug report Message-ID: <40A5D026.5080608@dirk-herrmanns-seiten.de> Hi folks, I had sent the below bug report, but never got an answer. Best regards Dirk Herrmann -------- Original Message -------- Subject: Bug reports Date: Mon, 10 Nov 2003 08:14:49 +0100 From: Dirk Herrmann To: splint-bug@cs.virginia.edu Hi folks, thanks a lot for providing splint. First, something easy: The text Name memoize_exprs is reserved for future library extensions. Functions that begin with "mem" or "wcs" and a lowercase letter letter may be added to . (ISO:7.26.11) has a double "letter" in it. Second, the following file (if you name it splint-bug.c) gives error messages if checked with "splint splint-bug.c": ------------ Beginning of file ------------ #define SCM_MOST_NEGATIVE_FIXNUM (-SCM_MOST_POSITIVE_FIXNUM-1) /* SCM_SRS is signed right shift */ #if (-1 == (((-1) << 2) + 2) >> 2) # define SCM_SRS(x, y) ((x) >> (y)) #else # define SCM_SRS(x, y) ((x) < 0 ? ~((~(x)) >> (y)) : ((x) >> (y))) #endif /* (-1 == (((-1) << 2) + 2) >> 2) */ ------------ End of file ------------ Output: > splint splint-bug.c Splint 3.1.1 --- 28 Apr 2003 general.c:352: at source point splint-bug.c:1:1: *** Internal Bug at general.c:352: llassert failed: x >= 0 [errno: 2] *** Please report bug to splint-bug@splint.org *** (attempting to continue, results may be incorrect) general.c:352: at source point splint-bug.c:1:1: *** Internal Bug at general.c:352: llassert failed: x >= 0 [errno: 2] *** Please report bug to splint-bug@splint.org *** (attempting to continue, results may be incorrect) general.c:352: at source point splint-bug.c:1:1: *** Internal Bug at general.c:352: llassert failed: x >= 0 [errno: 2] *** Please report bug to splint-bug@splint.org *** (attempting to continue, results may be incorrect) Finished checking --- no warnings That's it. Thanks a lot again. Dirk Herrmann From dirk at dirk-herrmanns-seiten.de Sat May 15 04:16:35 2004 From: dirk at dirk-herrmanns-seiten.de (Dirk Herrmann) Date: Wed Mar 22 17:10:33 2006 Subject: [splint-discuss] Feature suggestion: Handling redundant default cases in switch. Message-ID: <40A5D1E3.6090803@dirk-herrmanns-seiten.de> Hi, for switch statements where the condition is an enumeration, splint checks whether all elements of the enumeration appear as case statements. However, if there are really all enumeration elements handled in case statements, a default case should not be necessary any more. Certainly, many people prefer to have a default case also, but it could also just be a mistake. Wouldn't it make sense to add this as a check to lint? Best regards, Dirk Herrmann From dirk at dirk-herrmanns-seiten.de Sat May 15 04:22:44 2004 From: dirk at dirk-herrmanns-seiten.de (Dirk Herrmann) Date: Wed Mar 22 17:10:33 2006 Subject: [splint-discuss] Bug report: Missing semicolon after a struct is not detected. Message-ID: <40A5D354.6000202@dirk-herrmanns-seiten.de> Hi folks, splint does not give any error for the following piece of code: ------ begin ------ struct x { int i; } /* missing semicolon */ struct y { int i; }; ------ end ------ > splint splint-1.c Splint 3.1.1 --- 28 Apr 2003 Finished checking --- no warnings Best regards, Dirk Herrmann From dirk at dirk-herrmanns-seiten.de Sat May 15 04:27:15 2004 From: dirk at dirk-herrmanns-seiten.de (Dirk Herrmann) Date: Wed Mar 22 17:10:33 2006 Subject: [splint-discuss] Bug report: missing include of stdint.h is not detected. Message-ID: <40A5D463.6000000@dirk-herrmanns-seiten.de> Hi folks, splint does not give any warning for the following code: ------ begin ------ int8_t x; ------ end ------ > splint splint-1.c Splint 3.1.1 --- 28 Apr 2003 Finished checking --- no warnings splint does not indicate that int8_t is defined by ISO-C99, but can only be used if stdint.h is included. Best regards, Dirk Herrmann From dirk at dirk-herrmanns-seiten.de Sat May 15 04:31:00 2004 From: dirk at dirk-herrmanns-seiten.de (Dirk Herrmann) Date: Wed Mar 22 17:10:33 2006 Subject: [splint-discuss] Feature request: Make standard version selectable Message-ID: <40A5D544.90906@dirk-herrmanns-seiten.de> Hi folks, splint does accept, if after the last element of an enumeration there follows a colon. This, however is AFAIK only accepted since ISO-C99. If one wants to provide code that is also compiled with older compilers, such constructs should be avoided. Thus, I suggest to issue error messages for code that is only accepted for ISO-C99. They could be disabled by setting some option to select ISO-C99 compatibility. Alternatively, it could be done on a feature-basis. Best regards, Dirk Herrmann From evans at virginia.edu Tue May 18 15:08:02 2004 From: evans at virginia.edu (David Evans) Date: Wed Mar 22 17:10:34 2006 Subject: [splint-discuss] Re: Repeated: Bug report In-Reply-To: <40A5D026.5080608@dirk-herrmanns-seiten.de> References: <40A5D026.5080608@dirk-herrmanns-seiten.de> Message-ID: > -------- Original Message -------- > Subject: Bug reports > Date: Mon, 10 Nov 2003 08:14:49 +0100 > From: Dirk Herrmann > To: splint-bug@cs.virginia.edu > > Hi folks, > > thanks a lot for providing splint. First, something easy: The text > Name memoize_exprs is reserved for future library extensions. > Functions that begin with "mem" or "wcs" and a lowercase > letter letter may be added to . (ISO:7.26.11) > has a double "letter" in it. > I don't understand. Splint checks for reserved names, and reports a warning for memoize_exprs (if +isoreserved is set), which I believe is correct. > Second, the following file (if you name it splint-bug.c) gives error > messages if checked with "splint splint-bug.c": Thanks for reporting the problem. Splint is doing overly agressive sanity checking on macro expressions. However, the meaning of a shift where the operand is negative is implementation defined. This is fixed in the CVS development code now. --- Dave From roland.illig at gmx.de Fri May 21 04:20:40 2004 From: roland.illig at gmx.de (Roland Illig) Date: Wed Mar 22 17:10:34 2006 Subject: [splint-discuss] va_copy Message-ID: <40ADBBD8.9050401@gmx.de> Hi, I think standard.h should include the va_copy macro, defined in C99. Anything against? Roland From evans at cs.virginia.edu Fri May 21 08:58:17 2004 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:10:34 2006 Subject: [splint-discuss] va_copy In-Reply-To: <40ADBBD8.9050401@gmx.de> References: <40ADBBD8.9050401@gmx.de> Message-ID: Yes, it should be in standard.h. I have added: void va_copy (/*@out@*/ va_list dest, va_list src) /*modifies dest;@*/ ; to standard.h (in the CVS development code). --- Dave On Fri, 21 May 2004, Roland Illig wrote: > Hi, > > I think standard.h should include the va_copy macro, defined in C99. > Anything against? > > Roland > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss > From dirk at dirk-herrmanns-seiten.de Fri May 21 15:45:07 2004 From: dirk at dirk-herrmanns-seiten.de (Dirk Herrmann) Date: Wed Mar 22 17:10:34 2006 Subject: [splint-discuss] Re: Repeated: Bug report In-Reply-To: References: <40A5D026.5080608@dirk-herrmanns-seiten.de> Message-ID: <40AE5C43.5080705@dirk-herrmanns-seiten.de> David Evans wrote: > > -------- Original Message -------- Subject: Bug reports Date: Mon, > > 10 Nov 2003 08:14:49 +0100 From: Dirk Herrmann > > To: splint-bug@cs.virginia.edu > > > > Hi folks, > > > > thanks a lot for providing splint. First, something easy: The > > text Name memoize_exprs is reserved for future library extensions. > > Functions that begin with "mem" or "wcs" and a lowercase letter > > letter may be added to . (ISO:7.26.11) has a double > > "letter" in it. > > I don't understand. Splint checks for reserved names, and reports a > warning for memoize_exprs (if +isoreserved is set), which I believe > is correct. Sorry for the confusion, I was just referring to the typo in the text of the message printed by splint. The message text holds the word "letter" twice. Best regards Dirk Herrmann From michael.winkler at lvf.liebherr.com Wed May 26 08:28:15 2004 From: michael.winkler at lvf.liebherr.com (Winkler Michael (LVF)) Date: Wed Mar 22 17:10:34 2006 Subject: [splint-discuss] Duplicate short qualifier??? Message-ID: <50750E91AE69D3118A5E0000E85F01AA027B94A1@LVF-MAIL> Line in Header file: typedef short INT16S; Warning: Duplicate type qualifiers not supported by ISO standard. (Use -duplicatequals to inhibit warning) Why??? Mit freundlichen Gr??en Michael Winkler Systemtechnik / Elektronik LIEBHERR-TRANSPORTATION SYSTEMS GMBH Liebherrstra?e 1 A-2100 Korneuburg Phone: +43 (0) 2262 602 364 Fax: +43 (0) 2262 602 503 michael.winkler@lvf.liebherr.com www.liebherr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20040526/f68244a8/attachment.htm From derek at knosof.co.uk Wed May 26 09:12:06 2004 From: derek at knosof.co.uk (Derek M Jones) Date: Wed Mar 22 17:10:34 2006 Subject: [splint-discuss] Duplicate short qualifier??? In-Reply-To: <50750E91AE69D3118A5E0000E85F01AA027B94A1@LVF-MAIL> Message-ID: <4.3.2.7.2.20040526141036.00b365f0@pop3.demon.co.uk> >Warning: >Duplicate type qualifiers not supported by ISO standard. (Use -duplicatequals to inhibit warning) Duplicate type qualifiers are not permitted in C90. However, the latest C Standard, C99, permits duplicate qualifiers. derek -- Derek M Jones tel: +44 (0) 1252 520 667 Knowledge Software Ltd mailto:derek@knosof.co.uk Applications Standards Conformance Testing http://www.knosof.co.uk