From santosh.saxena at st.com Sun Mar 2 01:52:34 2003 From: santosh.saxena at st.com (Santosh Saxena) Date: Wed Mar 22 17:10:01 2006 Subject: [splint-discuss] How to use splint on pro*c programs In-Reply-To: <3E59575D.569F79B4@yahoo.com> Message-ID: <004e01c2e088$4dd4a1f0$3f9601ca@noida.dlh.st.com> How do I use splint on pro*c programs ? Regards, Santosh From narayan at tc4hq.cmcltd.com Sun Mar 2 04:04:59 2003 From: narayan at tc4hq.cmcltd.com (Narayan Kumar) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] How to use splint on pro*c programs In-Reply-To: <004e01c2e088$4dd4a1f0$3f9601ca@noida.dlh.st.com> Message-ID: Hai Santosh, I tried running splint on the 'C' file that the Pro*C generates after precompiling. I could not find a way to remove those extra warnings that SPLINT gives for the transformed SQL statements. Commenting the SQL statements before precompilation helped me to some extent. I remember having put this question before you did to this group, and I did not get any reply. Best of Luck! -- Narayan Will India Make It This Time? On Sun, 2 Mar 2003, Santosh Saxena wrote: |How do I use splint on pro*c programs ? | |Regards, |Santosh | |_______________________________________________ |splint-discuss mailing list |splint-discuss@cs.virginia.edu |http://www.splint.org/mailman/listinfo/splint-discuss | From santosh.saxena at st.com Thu Mar 6 23:11:56 2003 From: santosh.saxena at st.com (Santosh Saxena) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] Simple case of infinite loop Message-ID: <000001c2e45f$b14c0310$3f9601ca@noida.dlh.st.com> Can someone explain me why splint is not able to detect 'infinite loop' in the following code. What should be the actual usage of splint in this case so as to detect the infinite loop. Currently even +infloopsuncon does not detect this case.. #include int func(int j) { int i,j=0; for(i=0; i<10; ) { j = j + 1; } return j; } Regards, Santosh From mhjohnson at mac.com Sat Mar 8 11:05:41 2003 From: mhjohnson at mac.com (Mark Johnson) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] HOWTO query Message-ID: I have gone through the manual and a few of the papers, but when and how to make annotations is not clear. Has someone put together a "how to annotate", FAQ, or similar guide to Splint? If so - where? If not, I'm willing to help put one together, but need a better understanding of the "real rules". Here are a few examples / questions raised: A function like fopen can return NULL. So a function like void log_on(void) { static char *logfile = "logfile"; /* name of log file */ if ((fecho = fopen(logfile, "w")) == NULL) { logging = 0; } else { (void)fprintf(fecho, "Roman log file.\n\n"); logging = 1; } } will generate warnings such as % splint player.c io.c Splint 3.0.1.6 --- 03 Mar 2003 io.c: (in function log_on) io.c:69:36: Observer storage assigned to unqualified reference: char * logfile = "logfile" = "logfile" Observer storage is transferred to a non-observer reference. (Use -observertrans to inhibit warning) io.c:69:26: Storage becomes observer io.c:80:2: Function returns with non-null global fecho referencing null storage A global variable does not satisfy its annotations when control is transferred. (Use -globstate to inhibit warning) io.c:71:16: Storage fecho may become null Finished checking --- 2 code warnings For the first warning, the manual does not provide any clear explanation of what "observer storage" is or how it should be handled. - observer is not in the index - storage model is in the index, refers to section 5 which doesn't describe observer storage - there is an oblique reference in Appendix C (which points to 6.2.1) The last one talks about functions, not storage declarations, but apparently changing it to static char /*@observer@*/ *logfile = "logfile"; /* name of log file */ makes the warning go away. Do I need to add that annotation whenever I initialize a string? If so, why? The definition of fopen does not have any special annotations about NULL values, but this function seems to need some according to Splint. I also tried static FILE /*@relnull@*/ *fecho; /* record the action */ but that did not help either. The warning suggests -globstate, but that appears to be a global flag - not one local to this specific case. In addition, I noticed the declarations for fdopen and fopen vary as follows: extern /*@null@*/ /*@dependent@*/ FILE *fdopen (int fd, const char *type) /*@modifies errno, fileSystem@*/; extern FILE * fopen (char *filename, char *mode) /*@modifies errno, fileSystem;@*/ ; which would imply that fopen should be returning null / dependent references as well. Is there some reason for this difference? Thanks. --Mark From cbfalconer at yahoo.com Sat Mar 8 12:45:36 2003 From: cbfalconer at yahoo.com (CBFalconer) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] HOWTO query References: Message-ID: <3E6A2C40.CF744DC9@yahoo.com> Mark Johnson wrote: > > I have gone through the manual and a few of the papers, but when and > how to make annotations is not clear. Has someone put together a "how > to annotate", FAQ, or similar guide to Splint? If so - where? If not, > I'm willing to help put one together, but need a better understanding > of the "real rules". > > Here are a few examples / questions raised: > > A function like fopen can return NULL. So a function like > > void log_on(void) > { > static char *logfile = "logfile"; /* name of log file */ > > if ((fecho = fopen(logfile, "w")) == NULL) > { > logging = 0; > } > else > { > (void)fprintf(fecho, "Roman log file.\n\n"); > logging = 1; > } > } > > will generate warnings such as > % splint player.c io.c > Splint 3.0.1.6 --- 03 Mar 2003 > > io.c: (in function log_on) > io.c:69:36: Observer storage assigned to unqualified reference: > char * logfile = "logfile" = "logfile" > Observer storage is transferred to a non-observer reference. (Use > -observertrans to inhibit warning) > io.c:69:26: Storage becomes observer > io.c:80:2: Function returns with non-null global fecho referencing null > storage > A global variable does not satisfy its annotations when control is > transferred. (Use -globstate to inhibit warning) > io.c:71:16: Storage fecho may become null > > Finished checking --- 2 code warnings In this case I think you should review your code, and splint is telling you so. To start with, what possible purpose can the logfile variable serve? You could better eliminate it and write: if ((fecho = fopen("logfile", "w")) == NULL) or even #define logfile "logfile" secondly, you would be better off defining the function to return a FILE*, and arrange for the caller to place that where it wishes. Similarly you would be better off passing in a pointer to the logging variable. This would make the prototype: FILE* logon(int *success); with fecho a local variable of type FILE*. You can do all this with NO modifications to your existing code, except for the calls to logon(), which would become: fecho = logon(&logging); and give the reader a clear idea of what is going on, without having to refer to the logon coding. Meanwhile logon() stands by itself, and can be modified and embellished without worrying about affecting other code, provided that the prototype is unaltered. Eliminating globals generally improves code and reduces incidental connectivity. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! From mhjohnson at mac.com Sat Mar 8 17:21:18 2003 From: mhjohnson at mac.com (Mark Johnson) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] HOWTO query In-Reply-To: <3E6A2C40.CF744DC9@yahoo.com> Message-ID: <4871C3FE-51B4-11D7-984E-0030653F09E8@mac.com> On Saturday, March 8, 2003, at 11:45 AM, CBFalconer wrote: > Mark Johnson wrote: >> [snip - request for FAQ] I would still like an answer to this part. >> A function like fopen can return NULL. So a function like >> >> void log_on(void) >> { >> static char *logfile = "logfile"; /* name of log file */ >> >> if ((fecho = fopen(logfile, "w")) == NULL) >> { >> logging = 0; >> } >> else >> { >> (void)fprintf(fecho, "Roman log file.\n\n"); >> logging = 1; >> } >> } >> >> will generate warnings such as >> % splint player.c io.c >> Splint 3.0.1.6 --- 03 Mar 2003 >> >> io.c: (in function log_on) >> io.c:69:36: Observer storage assigned to unqualified reference: >> char * logfile = "logfile" = "logfile" >> Observer storage is transferred to a non-observer reference. (Use >> -observertrans to inhibit warning) >> io.c:69:26: Storage becomes observer >> io.c:80:2: Function returns with non-null global fecho referencing >> null >> storage >> A global variable does not satisfy its annotations when control is >> transferred. (Use -globstate to inhibit warning) >> io.c:71:16: Storage fecho may become null >> >> Finished checking --- 2 code warnings > > In this case I think you should review your code, and splint is > telling you so. To start with, what possible purpose can the > logfile variable serve? You could better eliminate it and write: > > if ((fecho = fopen("logfile", "w")) == NULL) > or even > #define logfile "logfile" > Either of these methods hardwire the name of the log file and I don't want to do that. I do want a default value for the name of the log file and if the user overrides it - then use that instead. The example I provided is a far simpler version of what is really being done. My question is more general - how do you define a character string and assign an initial value to it without requiring annotations? If you cannot - what is the correct annotation to use? I want to be able to use forms like char x[] = "xxx"; and char *x = "xxx"; the former allocates storage & initializes it (and can be modified, so the observer annotation is not suitable). > secondly, you would be better off defining the function to return > a FILE*, and arrange for the caller to place that where it > wishes. Similarly you would be better off passing in a pointer to > the logging variable. This would make the prototype: > > FILE* logon(int *success); > > with fecho a local variable of type FILE*. > That is certainly feasible but I would rather hide the existence of FILE* fecho in a single source file. Callers to log_on, log_text, and others would then not have to handle the FILE* pointer. See also the next comment. > You can do all this with NO modifications to your existing code, > except for the calls to logon(), which would become: > > fecho = logon(&logging); > > and give the reader a clear idea of what is going on, without > having to refer to the logon coding. Meanwhile logon() stands by > itself, and can be modified and embellished without worrying about > affecting other code, provided that the prototype is unaltered. > As I understand this situation, that merely moves the problem to the caller. Since fecho may be NULL after returning from log_on() the problem moves from log_on() to every caller of log_on(). That combined with the reasons listed above sound like a lose to me. Let me repeat my question - how can this code be annotated to eliminate the warning for fecho [and not every global / static variable I use]. --Mark From austin_hastings at yahoo.com Mon Mar 10 11:09:32 2003 From: austin_hastings at yahoo.com (Austin Hastings) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] HOWTO query In-Reply-To: <4871C3FE-51B4-11D7-984E-0030653F09E8@mac.com> Message-ID: <20030310160932.70959.qmail@web12303.mail.yahoo.com> > Let me repeat my question - how can this code be annotated to > eliminate > the warning for fecho [and not every global / static variable I use]. > --Mark Below is a quote from section 6.2.1 of the manual. (I did a MSWord search for "observer" from the top.) Note especially the final paragraph, in conjunction with your earlier question about declarations and observer storage. Note also that you never showed us the declaration of fecho, so any annotations that it may have (even implicit ones, like "observer", are concealed. =Austin [cite] 6.2.1 Read-Only Storage It is often useful for a function to return a pointer to internal storage (or an instance of a mutable abstract type) that is intended only as an observer. The caller may use the result, but should not modify the storage it points to. For example, consider a naïve implementation of the employee_getName operation for the abstract employee type: typedef /*@abstract@*/ struct { char *name; int id; } *employee; … char *employee_getName (employee e) { return e->name; } Splint produces a message to indicate that the return value exposes the representation. One solution would be to return a fresh copy of e->name. This is expensive, though, especially if we expect employee_getName is used mainly just to get a string for searching or printing. Instead, we could change the declaration of employee_getName to: extern /*@observer@*/ char *employee_getName (employee e); Now, the original implementation is correct. The declaration indicates that the caller may not modify the result, so it is acceptable to return shared storage. (The program must also not use the returned observer storage after any other calls to the abstract type module using the same parameter. Splint does not attempt to check this, and in practice it is rarely a problem.) Splint checks that the caller does not modify the return value. An error is reported if observer storage is modified directly, passed as a function parameter that may be modified, assigned to a global variable or reference derivable from a global variable that is not declared with an observer annotation , or returned as a function result or a reference derivable from the function result that is not annotation with an observer annotation. String Literals A program that attempts to modify a string literal has undefined behavior [ISO, 6.4.5]. This is not enforced by most C compilers, and can lead to particularly pernicious bugs that only appear when optimizations are turned on and the compiler attempts to minimize storage for string literals. Splint can be used to check that string literals are not modified, by treating them as -observer storage. If +read-only-strings is set (default in standard mode), Splint will report an error if a string literal is modified. [/cite] --- Mark Johnson wrote: > On Saturday, March 8, 2003, at 11:45 AM, CBFalconer wrote: > > > Mark Johnson wrote: > >> [snip - request for FAQ] > I would still like an answer to this part. > > >> A function like fopen can return NULL. So a function like > >> > >> void log_on(void) > >> { > >> static char *logfile = "logfile"; /* name of log file */ > >> > >> if ((fecho = fopen(logfile, "w")) == NULL) > >> { > >> logging = 0; > >> } > >> else > >> { > >> (void)fprintf(fecho, "Roman log file.\n\n"); > >> logging = 1; > >> } > >> } > >> > >> will generate warnings such as > >> % splint player.c io.c > >> Splint 3.0.1.6 --- 03 Mar 2003 > >> > >> io.c: (in function log_on) > >> io.c:69:36: Observer storage assigned to unqualified reference: > >> char * logfile = "logfile" = "logfile" > >> Observer storage is transferred to a non-observer reference. > (Use > >> -observertrans to inhibit warning) > >> io.c:69:26: Storage becomes observer > >> io.c:80:2: Function returns with non-null global fecho referencing > > >> null > >> storage > >> A global variable does not satisfy its annotations when control > is > >> transferred. (Use -globstate to inhibit warning) > >> io.c:71:16: Storage fecho may become null > >> > >> Finished checking --- 2 code warnings > > > > In this case I think you should review your code, and splint is > > telling you so. To start with, what possible purpose can the > > logfile variable serve? You could better eliminate it and write: > > > > if ((fecho = fopen("logfile", "w")) == NULL) > > or even > > #define logfile "logfile" > > > Either of these methods hardwire the name of the log file and I don't > > want to do that. I do want a default value for the name of the log > file > and if the user overrides it - then use that instead. The example I > provided is a far simpler version of what is really being done. > > My question is more general - how do you define a character string > and > assign an initial value to it without requiring annotations? If you > cannot - what is the correct annotation to use? I want to be able to > use forms like > char x[] = "xxx"; > and > char *x = "xxx"; > the former allocates storage & initializes it (and can be modified, > so > the observer annotation is not suitable). > > > secondly, you would be better off defining the function to return > > a FILE*, and arrange for the caller to place that where it > > wishes. Similarly you would be better off passing in a pointer to > > the logging variable. This would make the prototype: > > > > FILE* logon(int *success); > > > > with fecho a local variable of type FILE*. > > > That is certainly feasible but I would rather hide the existence of > FILE* fecho in a single source file. Callers to log_on, log_text, and > > others would then not have to handle the FILE* pointer. See also the > next comment. > > > You can do all this with NO modifications to your existing code, > > except for the calls to logon(), which would become: > > > > fecho = logon(&logging); > > > > and give the reader a clear idea of what is going on, without > > having to refer to the logon coding. Meanwhile logon() stands by > > itself, and can be modified and embellished without worrying about > > affecting other code, provided that the prototype is unaltered. > > > As I understand this situation, that merely moves the problem to the > caller. Since fecho may be NULL after returning from log_on() the > problem moves from log_on() to every caller of log_on(). That > combined > with the reasons listed above sound like a lose to me. > > Let me repeat my question - how can this code be annotated to > eliminate > the warning for fecho [and not every global / static variable I use]. > --Mark > > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss From Fabrizio.Sensini at st.com Fri Mar 21 10:10:03 2003 From: Fabrizio.Sensini at st.com (Fabrizio Sensini) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] GCC extensions in splint Message-ID: <3E7B2B4B.7340ED9E@st.com> Hello All, I am trying to use splint for checking some linux device code I've written. I understand that this is not ensured to work, as parsing of the linux kernel headers can give a number problems, mostly related to parsing. So the 1st question should be whether there is expectation that this should work - or some evidence that it has. Anyway, since I've tried to do it anyway, I've come with the simple program below which gets compiled by gcc, but generates a parse error with splint. The error is probably due to the presence of a struct initialiser used as an R-value. typedef struct __wait_queue_head wait_queue_head_t; typedef struct { int gcc_is_buggy; } rwlock_t; #define wq_lock_t rwlock_t #define RW_LOCK_UNLOCKED (rwlock_t) { 0 } # define WAITQUEUE_RW_LOCK_UNLOCKED RW_LOCK_UNLOCKED struct __wait_queue_head { rwlock_t lock; int task_list; long __magic; long __creator; }; int main() { wait_queue_head_t *q; wait_queue_head_t qq; q = &qq; q->lock = WAITQUEUE_RW_LOCK_UNLOCKED; /*this causes the parse error */ } Does anybody know a way to get around this problem? I've tried with gnuextensions and trytorecover without success - is there anything else I could try? Many thanks Fabrizio -- Fabrizio Sensini - CBU Catania App&Mware team - STMicroelectronics Strada Ottava - Zona Industriale - 95121 Catania - Italia tel: +39 095 740 4556 fax: +39 095 740 4008 Mailto:Fabrizio.Sensini@st.com From david.chabal at c-s.fr Mon Mar 24 05:30:27 2003 From: david.chabal at c-s.fr (CHABAL David) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] bounds checking, array & pointers Message-ID: <3E7EDE43.AACFD2B6@c-s.fr> Hello, I want to check array over/underflow in my source code (I only have static memory allocation because it's for an embedded software). I saw the "+bounds" option in the splint doc, but in the small example below, there is a false warning: ----------------------------------------- static int i; int main (void) { int t[5]; int *p=&i; t[5] = 123; <-- stupid error !!! *p=3; <-- correct code return 0; } ----------------------------------------- > splint +bounds tutu.c Splint 3.0.1.6 --- 11 Feb 2002 tutu.c: (in function main) tutu.c:8:2: Possible out-of-bounds store: t[5] Unable to resolve constraint: requires 4 >= 5 needed to satisfy precondition: requires maxSet(t @ tutu.c:8:2) >= 5 A memory write may write to an address beyond the allocated buffer. (Use -boundswrite to inhibit warning) tutu.c:10:2: Possible out-of-bounds store: *p Unable to resolve constraint: requires maxSet(&i @ tutu.c:6:9) >= 0 needed to satisfy precondition: requires maxSet(p @ tutu.c:10:3) >= 0 Finished checking --- 2 code warnings ----------------------------------------- I have a lot of data accessed by pointer in my code, so I don't want to check manually each warning. Is there an magic option to sort only the out-of-bounds on arrays and not on pointers ? TIA David -- ------------------------------------------------------------------ David CHABAL CS SI / Logiciel embarqu? spatial ZAC de la Grande Plaine rue Brindejonc des Moulinais BP 5872 31506 Toulouse Cedex 6 - France T?l. direct : 05 61 17 65 48 T?l. standard : 05 61 17 66 66 Fax : 05 61 17 65 78 mailto:david.chabal@c-s.fr From cbfalconer at yahoo.com Mon Mar 24 07:35:44 2003 From: cbfalconer at yahoo.com (CBFalconer) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] bounds checking, array & pointers References: <3E7EDE43.AACFD2B6@c-s.fr> Message-ID: <3E7EFBA0.CA5C7F85@yahoo.com> CHABAL David wrote: > > I want to check array over/underflow in my source code (I only > have static memory allocation because it's for an embedded software). > > I saw the "+bounds" option in the splint doc, but in the small > example below, there is a false warning: > > ----------------------------------------- > static int i; > > int main (void) > { > int t[5]; > int *p=&i; > > t[5] = 123; /* <-- stupid error !!! */ > > *p=3; /* <-- correct code */ > > return 0; > } > ----------------------------------------- > > splint +bounds tutu.c It is not false - because of the loose treatment of pointers in C it has no idea what the bounds are for the pointer access. The warning appears even when the t[5] line is removed, and the potential harm is just as great. You should be able to handle it by hunting down assignments (not uses of) to the pointer and telling splint the specific boundaries involved for the usage. This is basically why C cannot be a safe language. Note that including "p = &t[0]" or "p = t" avoids the error. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! From marfis at despammed.com Mon Mar 24 09:46:08 2003 From: marfis at despammed.com (marfis@despammed.com) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] char constant assignment Message-ID: <200303241446.JAA29529@despammed.com> Hello All, unsigned char n; n = 1; results in "Assignment of int to unsigned char". What the clean way to avoid these messages? Since I use _many_ 8 Bit variables, it would be annoying to cast each constant. TiA From david.chabal at c-s.fr Mon Mar 24 10:19:45 2003 From: david.chabal at c-s.fr (CHABAL David) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] char constant assignment References: <200303241446.JAA29529@despammed.com> Message-ID: <3E7F2211.465A8FD1@c-s.fr> Hello, Try to run splint with the +charint option. David marfis@despammed.com a ?crit : > > Hello All, > > unsigned char n; > n = 1; > > results in "Assignment of int to unsigned char". > > What the clean way to avoid these messages? > > Since I use _many_ 8 Bit variables, it would be annoying to cast each constant. > > TiA > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss -- ------------------------------------------------------------------ David CHABAL CS SI / Logiciel embarqu? spatial ZAC de la Grande Plaine rue Brindejonc des Moulinais BP 5872 31506 Toulouse Cedex 6 - France T?l. direct : 05 61 17 65 48 T?l. standard : 05 61 17 66 66 Fax : 05 61 17 65 78 mailto:david.chabal@c-s.fr From david.chabal at c-s.fr Mon Mar 24 10:26:38 2003 From: david.chabal at c-s.fr (CHABAL David) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] bounds checking, array & pointers References: <3E7EDE43.AACFD2B6@c-s.fr> <3E7EFBA0.CA5C7F85@yahoo.com> Message-ID: <3E7F23AE.7FEF16D0@c-s.fr> Thanks for you answer, I can't modify my code because I have more than 100k lines, so I develop a script to grep splint's results. David CBFalconer a ?crit : > > CHABAL David wrote: > > > > I want to check array over/underflow in my source code (I only > > have static memory allocation because it's for an embedded software). > > > > I saw the "+bounds" option in the splint doc, but in the small > > example below, there is a false warning: > > > > ----------------------------------------- > > static int i; > > > > int main (void) > > { > > int t[5]; > > int *p=&i; > > > > t[5] = 123; /* <-- stupid error !!! */ > > > > *p=3; /* <-- correct code */ > > > > return 0; > > } > > ----------------------------------------- > > > splint +bounds tutu.c > > It is not false - because of the loose treatment of pointers in C > it has no idea what the bounds are for the pointer access. The > warning appears even when the t[5] line is removed, and the > potential harm is just as great. You should be able to handle it > by hunting down assignments (not uses of) to the pointer and > telling splint the specific boundaries involved for the usage. > This is basically why C cannot be a safe language. > > Note that including "p = &t[0]" or "p = t" avoids the error. > > -- > Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) > Available for consulting/temporary embedded and systems. > USE worldnet address! > > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss -- ------------------------------------------------------------------ David CHABAL CS SI / Logiciel embarqu? spatial ZAC de la Grande Plaine rue Brindejonc des Moulinais BP 5872 31506 Toulouse Cedex 6 - France T?l. direct : 05 61 17 65 48 T?l. standard : 05 61 17 66 66 Fax : 05 61 17 65 78 mailto:david.chabal@c-s.fr From marfis at despammed.com Mon Mar 24 10:38:39 2003 From: marfis at despammed.com (marfis@despammed.com) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] char constant assignment Message-ID: <200303241538.KAA12869@despammed.com> CHABAL David wrote: > > Try to run splint with the +charint option. But then Splint doesn't warn for the real dangerous things as assigning int variables to char variables. Markus From david.chabal at c-s.fr Mon Mar 24 11:10:23 2003 From: david.chabal at c-s.fr (CHABAL David) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] char constant assignment References: <200303241538.KAA12869@despammed.com> Message-ID: <3E7F2DEF.6C79E761@c-s.fr> It's true, but when you assign a value too large, your compiler warns for it. David marfis@despammed.com a ?crit : > > CHABAL David wrote: > > > > Try to run splint with the +charint option. > > But then Splint doesn't warn for the real dangerous things as assigning int variables to char variables. > > Markus > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss -- ------------------------------------------------------------------ David CHABAL CS SI / Logiciel embarqu? spatial ZAC de la Grande Plaine rue Brindejonc des Moulinais BP 5872 31506 Toulouse Cedex 6 - France T?l. direct : 05 61 17 65 48 T?l. standard : 05 61 17 66 66 Fax : 05 61 17 65 78 mailto:david.chabal@c-s.fr From stephane.martin at ca.kontron.com Mon Mar 24 11:29:49 2003 From: stephane.martin at ca.kontron.com (=?iso-8859-1?Q?=22Martin=2C_St=E9phane=22?=) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] char constant assignment Message-ID: <5009AD9521A8D41198EE00805F85F18F03A85E81@sembo111.teknor.com> Markus, You are right. I have sent the e-mail bellow long time ago but it seems that guys from Splint are not willing to include this improvement yet. Probably because this constraint does not affect desktop machine that have larger memory and where "int" is used everywhere. A splint directive that says: relax check on numerical literal below 256 would be great. This way a unsigned char that is initialized to a numerical below 256 wont produce any warning. However, Splint is a great tool and we choose to cast all numerical literal everywhere in our code (it is very anoying!!!). But I still bellive such option will enforce the type checking. For now if I write: unsigned char Var = (unsigned char)1024; splint wont complain and Var will overflow!!! but it will send a Warning if this option was implemented. Stephane ######################################################### Is there a way to keep a "relative strong type checking" without always casting numeric literal when using unsigned char. Since my code run on a microcontroller with only internal RAM, I must keep the stack usage low, this is why I insist to use unsigned char whenever it is possible. My concern is because each time I define an unsigned char or I use it within a comparaison, I must cast the initializer or the comparator such as: unsigned char testedUchar = (unsigned char)10; ... if(testedUchar< (unsigned char)5) { do something.... Globaly this make the code less readable. I have tried many Splint setting such as :relaxquals, numliteral, charintliteral. The only setting that avoid Splint warning is +charint. However, this setting is less than "relative strong type checking" since a code such as: =================== /* Splint Directives */ /*@i@*/ /*@+standard@*/ /*@-varuse@*/ /*@+charint@*/ void main(void) { unsigned char testedUchar1 = 256; /* <----big problem here */ unsigned char testedUchar2 = 255; unsigned int testedInt1 = 65535; testedUchar1 = testedInt1; <----big problem here */ } ########################################################## >CHABAL David wrote: > > Try to run splint with the +charint option. >But then Splint doesn't warn for the real dangerous things as assigning int variables to char variables. >Markus ------------------------------------------------------------- Stephane Martin, ing. xxxxxx Canada Low Level Software Engineer 616 Cure-Boivin From stephane.martin at ca.kontron.com Mon Mar 24 11:32:08 2003 From: stephane.martin at ca.kontron.com (=?iso-8859-1?Q?=22Martin=2C_St=E9phane=22?=) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] char constant assignment Message-ID: <5009AD9521A8D41198EE00805F85F18F03A85E84@sembo111.teknor.com> Yes but if you want to use splint, you probably have casted the literal and this prevent the compiler to warn about the situation. ------------------------------------------------------------- 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: CHABAL David [SMTP:david.chabal@c-s.fr] > Sent: 24 mars, 2003 11:10 > To: marfis@despammed.com > Cc: splint-discuss@cs.virginia.edu > Subject: Re: [splint-discuss] char constant assignment > > > It's true, but when you assign a value too large, your compiler > warns for it. > > David > > marfis@despammed.com a ?crit : > > > > CHABAL David wrote: > > > > > > Try to run splint with the +charint option. > > > > But then Splint doesn't warn for the real dangerous things as assigning > int variables to char variables. > > > > Markus > > _______________________________________________ > > splint-discuss mailing list > > splint-discuss@cs.virginia.edu > > http://www.splint.org/mailman/listinfo/splint-discuss > > -- > ------------------------------------------------------------------ > David CHABAL > CS SI / Logiciel embarqu? spatial > ZAC de la Grande Plaine > rue Brindejonc des Moulinais > BP 5872 > 31506 Toulouse Cedex 6 - France > > T?l. direct : 05 61 17 65 48 > T?l. standard : 05 61 17 66 66 > Fax : 05 61 17 65 78 > mailto:david.chabal@c-s.fr > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss From austin_hastings at yahoo.com Mon Mar 24 13:19:06 2003 From: austin_hastings at yahoo.com (Austin Hastings) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] char constant assignment In-Reply-To: <5009AD9521A8D41198EE00805F85F18F03A85E81@sembo111.teknor.com> Message-ID: <20030324181906.66850.qmail@web12304.mail.yahoo.com> --- "Martin,_Stéphane" wrote: > Markus, You are right. I have sent the e-mail bellow long time ago > but it > seems that guys from Splint are not willing to include this > improvement yet. > Probably because this constraint does not affect desktop machine that > have > larger memory and where "int" is used everywhere. A splint directive > that > says: relax check on numerical literal below 256 would be great. > This way > a unsigned char that is initialized to a numerical below 256 wont > produce any warning. There is now at least one compiler whose unsigned character (and, in fact, whose "char" and signed char types) is larger than 8 bits -- requiring a flag to revert to 8-bit entities. (Unsurprisingly, it compiles to java "byte" code.) I agree that it would be nice to have a mode where ALL types did not warn as long as the assignment was in range. But it's not unreasonable for the splint folks to make that sort of thing an advanced, configurable feature, which may take a while. > However, Splint is a great tool and we choose to cast all numerical > literal > everywhere in our code (it is very anoying!!!). But I still bellive > such > option will enforce the type checking. For now if I write: > unsigned char Var = (unsigned char)1024; On the other hand, the fact that "Splint is forcing you to do this" makes a wonderful excuse for going through your code and replacing unsigned char Var = 5; with #define UCHAR(x) (unsigned char)(x) #define NUMBER_OF_PIGLETS UCHAR(5) unsigned char Var = NUMBER_OF_PIGLETS; =Austin From stevens_yin at oceanus.com.cn Mon Mar 24 21:33:45 2003 From: stevens_yin at oceanus.com.cn (stevens_yinoceanus) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] about internal doc Message-ID: <003c01c2f276$f56cb4c0$c801a8c0@stevens> where can i found some document about splint internal design? stevens yin From list_ob at gmx.net Tue Mar 25 03:47:44 2003 From: list_ob at gmx.net (Oliver Betz) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] char constant assignment In-Reply-To: <20030324181906.66850.qmail@web12304.mail.yahoo.com> References: <5009AD9521A8D41198EE00805F85F18F03A85E81@sembo111.teknor.com> Message-ID: <3E8025C0.27013.6403F1@localhost> Austin Hastings wrote: [...] > On the other hand, the fact that "Splint is forcing you to do this" > makes a wonderful excuse for going through your code and replacing > > unsigned char Var = 5; > > with > > #define UCHAR(x) (unsigned char)(x) > #define NUMBER_OF_PIGLETS UCHAR(5) That's IMHO a bad idea since you have no more range checking, als Stephane Martin already wrote. Therefore this method is a loss of security. An (ugly) alternative is to make the DEFINE UCHAR(x) dependent on S_SPLINT_S so that Splint is quiet but at least the compiler can warn. But I wouldn't do so. IMO, Splint is not very suitable for embedded development. At least at the moment, but there are no signs that this will change. One had to hide many (mostly non-ANSI, but widespread/de-facto- standard) extensions from Splint, e.g. "@" qualifiers like @interrupt or the @
construct. #pragma asm / endasm confuses the parser - no way to circumvent this even with Splint annotations and not so easy to hide. The Splint method is: make your code compliant and/or make your compiler compliant (hehe, try calling Cosmic/Metrowerks/HI- TECH/Imagecraft...), or let it be. But it is a great free tool for ANSI-compliant code. Oliver -- Oliver Betz, Muenchen From mne at mosaic-ag.com Tue Mar 25 02:11:14 2003 From: mne at mosaic-ag.com (Miroslaw Dobrzanski-Neumann) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] wide char Message-ID: <20030325071114.GB8996@mailsrv.mosaic-ag.com> Good morning, it seems to me that splint does not distinguish between char and wchar_t literals. $ cat x.c #include int f (wchar_t ch) { if (L'\0' == ch) return 1; else return 2; } $ splint x.c Splint 3.0.1.6 --- 11 Sep 2002 x.c: (in function f) x.c:5:6: Operands of == have incompatible types (char, wchar_t): L'\0' == ch Types are incompatible. (Use -type to inhibit warning) Finished checking --- 1 code warning please note L'\0' is a wide char literal and of type wchar_t and not char as splint insists on. BTW. You get the same kind of (splint)error if you work with wide strings as wchar_t const *const_str = L"abc"; Regards, Miroslaw -- Miroslaw Dobrzanski-Neumann E-mail: mne@mosaic-ag.com From richard at tartarus.org Tue Mar 25 04:27:45 2003 From: richard at tartarus.org (Richard Boulton) Date: Wed Mar 22 17:10:02 2006 Subject: [splint-discuss] Return by value and error codes Message-ID: <1048584465.16215.22.camel@scary.honest.gov> I'm trying to start using splint to check a moderately large project. This project makes widespread use of the following coding style: struct foo_ { int foo; }; typedef struct foo_ * foo; errCode make_new_foo(foo * res, ...) { ... } The implementation of make_new_foo is such that either a new foo object is returned in res and the return value is 0, or (on error) *res is set to NULL and a non-zero value is returned. Can anyone suggest a suitable annotation to describe this situation to splint? -- Richard Boulton From stephane.martin at ca.kontron.com Tue Mar 25 10:01:28 2003 From: stephane.martin at ca.kontron.com (=?iso-8859-1?Q?=22Martin=2C_St=E9phane=22?=) Date: Wed Mar 22 17:10:03 2006 Subject: [splint-discuss] char constant assignment Message-ID: <5009AD9521A8D41198EE00805F85F18F03A86115@sembo111.teknor.com> >Oliver Betz, Muenchen wrote: > On the other hand, the fact that "Splint is forcing you to do this" > makes a wonderful excuse for going through your code and replacing > > unsigned char Var = 5; > > with > > #define UCHAR(x) (unsigned char)(x) > #define NUMBER_OF_PIGLETS UCHAR(5) >That's IMHO a bad idea since you have no more range checking, als >Stephane Martin already wrote. >Therefore this method is a loss of security. Sure it is a loss of security. It is a matter of choice to use a Macro or not. I prefer to see a strait cast instead of a macro. This make more obvious on a formal code revew that something like: unsigned char Var = (unsigned char)1024; is wrong. However, this "visible" situation rarely occur, the numeral litteral is often hidden by a define wich make it harder to detect. >IMO, Splint is not very suitable for embedded development. At least >at the moment, but there are no signs that this will change. >One had to hide many (mostly non-ANSI, but widespread/de-facto- >standard) extensions from Splint, e.g. "@" qualifiers like @interrupt >or the @
construct. #pragma asm / endasm confuses the parser > -> no way to circumvent this even with Splint annotations and not so >easy to hide. I disagree with you, I have worked mostly on embedded projects running on microcontroller and where compiler are not as sofisticate as a GCC. Very large part of embedded code should be written in ANSI "C" and where Splint make a wonderful Job. My current code use a lot of #pragma inline , #pragma section, #pragma interrupt and it does not confuse Splint. Usualy asm code are contained under seperate file wich should not be provided to Splint. At last ressource, you can use Splint directive /*@i@*/ or /*@ignore@*/ - /*@end@*/ to hide embedded ASM instruction into "C" code. Our project is medium size for embeded microcontroller: Splint 3.0.1.6 --- 11 Feb 2002 Finished checking --- no warnings 233546 source lines in 145.98 s. The fact that numeral litteral below 256 must be casted to use an unsigned char is very anoying, however the fact that Splint perform strong checking on enum type ,null pointer and "use befor definition" and much more compensate a lot for that. The main reason why Splint is well suited for embedded project, is because it keep the quality of the static checks independent of the compiler wich may differ a lot from one microcontroller to another. > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss From list_ob at gmx.net Tue Mar 25 11:13:15 2003 From: list_ob at gmx.net (Oliver Betz) Date: Wed Mar 22 17:10:03 2006 Subject: [splint-discuss] char constant assignment In-Reply-To: <5009AD9521A8D41198EE00805F85F18F03A86115@sembo111.teknor.com> Message-ID: <3E808E2B.7574.17F9307@localhost> Martin, St?phane wrote: > Sure it is a loss of security. It is a matter of choice to use a Macro or > not. I prefer to see a strait cast instead of a macro. This make more > obvious on a formal code revew that something like: > unsigned char Var = (unsigned char)1024; > is wrong. However, this "visible" situation rarely occur, the numeral I want to use some kind of lint to do this, not my eyes. IMHO the idea behind static code checking is to check as much as possible in an automated manner. [is Splint suitable for embedded development?] [#pragma asm / endasm confuses the parser] > are contained under seperate file wich should not be provided to Splint. At Ack (that's the only solution I know). > last ressource, you can use Splint directive /*@i@*/ or /*@ignore@*/ - > /*@end@*/ to hide embedded ASM instruction into "C" code. As I wrote, the _parser_ isn't able to handle it. Try this: /*@ignore@*/ ldaa #1 /*@end@*/ Really worth looking at the output. So one shouldn't show Splint any assembler code, even when using /*@i@*/. > Our project is medium size for embeded microcontroller: > Splint 3.0.1.6 --- 11 Feb 2002 > Finished checking --- no warnings > 233546 source lines in 145.98 s. We are talking about _slightly_ different project sizes . I consider a "small uC" not to be capable of holding such projects, most times I stay below 10000 lines and the Controllers have 4KBytes ... 64KBytes ROM and 80Bytes ... several KBytes RAM, operate faster on 8 Bit data, therefore the widely used "char". [...] > The main reason why Splint is well suited for embedded project, is because > it keep the quality of the static checks independent of the compiler wich > may differ a lot from one microcontroller to another. That's a reason not to use Splint but a code checker capable to deal with different compilers. Certainly one _can_ use Splint for checking embedded stuff, but in many cases the additional work caused by Splint is worth buying another Lint. It's much more suitable for larger projects/processors. Oliver -- Oliver Betz, Muenchen From stephane.martin at ca.kontron.com Tue Mar 25 12:10:38 2003 From: stephane.martin at ca.kontron.com (=?iso-8859-1?Q?=22Martin=2C_St=E9phane=22?=) Date: Wed Mar 22 17:10:03 2006 Subject: [splint-discuss] char constant assignment Message-ID: <5009AD9521A8D41198EE00805F85F18F03A861B4@sembo111.teknor.com> >We are talking about _slightly_ different project sizes . I >consider a "small uC" not to be capable of holding such projects, >most times I stay below 10000 lines and the Controllers have 4KBytes >... 64KBytes ROM and 80Bytes ... several KBytes RAM, operate faster >on 8 Bit data, therefore the widely used "char". It is not a soo big microcontroller, it is a Hitachi 2148 with 4K of RAM (includind the stack!) and 128K of FLASH. I Hope these kind of mail thread will show to Splint developpement team that there is lots of interrets for Splint under embedded developpement. This will be my last mail for that specific thread Have a nice day Stephane ------------------------------------------------------------- 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: Oliver Betz [SMTP:list_ob@gmx.net] > Sent: 25 mars, 2003 11:13 > To: splint-discuss@cs.virginia.edu > Subject: RE: [splint-discuss] char constant assignment > > Martin, St?phane wrote: > > > Sure it is a loss of security. It is a matter of choice to use a Macro > or > > not. I prefer to see a strait cast instead of a macro. This make more > > obvious on a formal code revew that something like: > > unsigned char Var = (unsigned char)1024; > > is wrong. However, this "visible" situation rarely occur, the numeral > > I want to use some kind of lint to do this, not my eyes. IMHO the > idea behind static code checking is to check as much as possible in > an automated manner. > > [is Splint suitable for embedded development?] > > [#pragma asm / endasm confuses the parser] > > > are contained under seperate file wich should not be provided to Splint. > At > > Ack (that's the only solution I know). > > > last ressource, you can use Splint directive /*@i@*/ or /*@ignore@*/ - > > /*@end@*/ to hide embedded ASM instruction into "C" code. > > As I wrote, the _parser_ isn't able to handle it. Try this: > > /*@ignore@*/ > ldaa #1 > /*@end@*/ > > Really worth looking at the output. So one shouldn't show Splint any > assembler code, even when using /*@i@*/. > > > Our project is medium size for embeded microcontroller: > > Splint 3.0.1.6 --- 11 Feb 2002 > > Finished checking --- no warnings > > 233546 source lines in 145.98 s. > > We are talking about _slightly_ different project sizes . I > consider a "small uC" not to be capable of holding such projects, > most times I stay below 10000 lines and the Controllers have 4KBytes > ... 64KBytes ROM and 80Bytes ... several KBytes RAM, operate faster > on 8 Bit data, therefore the widely used "char". > > [...] > > > The main reason why Splint is well suited for embedded project, is > because > > it keep the quality of the static checks independent of the compiler > wich > > may differ a lot from one microcontroller to another. > > That's a reason not to use Splint but a code checker capable to deal > with different compilers. > > Certainly one _can_ use Splint for checking embedded stuff, but in > many cases the additional work caused by Splint is worth buying > another Lint. > > It's much more suitable for larger projects/processors. > > Oliver > -- > Oliver Betz, Muenchen > > > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss From evans at cs.virginia.edu Tue Mar 25 12:52:36 2003 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:10:03 2006 Subject: [splint-discuss] about internal doc In-Reply-To: <003c01c2f276$f56cb4c0$c801a8c0@stevens> References: <003c01c2f276$f56cb4c0$c801a8c0@stevens> Message-ID: There's no documentation about the internal design available other than what is available as comments in the source code and in the research papers about splint (http://www.splint.org/pubs.html). --- Dave On Tue, 25 Mar 2003, stevens_yinoceanus wrote: > where can i found some document about splint internal design? > > stevens yin > > _______________________________________________ > splint-discuss mailing list > splint-discuss@cs.virginia.edu > http://www.splint.org/mailman/listinfo/splint-discuss > From austin_hastings at yahoo.com Tue Mar 25 16:24:48 2003 From: austin_hastings at yahoo.com (Austin Hastings) Date: Wed Mar 22 17:10:03 2006 Subject: [splint-discuss] Q: Using splint in development of new code. In-Reply-To: Message-ID: <20030325212448.72959.qmail@web12306.mail.yahoo.com> Howdy, troop. I'm considering using splint for a large-scale open-source development effort that is currently in very early development, although a fair chunk of code has been written. This means that there's going to be a lot of code coming in, and most of it, initially, won't be annotated. (And some more, naturally, won't be annotated correctly.) So: Has anyone written an "annotation primer" that is a one or two page distillation of the splint manual? I'm envisioning something like this: When you're doing this: Annotate thus: - returning the only copy /*@only@*/ of a data item - temporarily using a data /*@temp@*/ item but not taking responsibility for it Maybe with more info, or less. Also, does anyone have any experience with implementing Splint on a large software project early in the development cycle -- what to expect, what payoffs, what kind of things are helpful? =Austin From cbfalconer at yahoo.com Tue Mar 25 18:05:22 2003 From: cbfalconer at yahoo.com (CBFalconer) Date: Wed Mar 22 17:10:03 2006 Subject: [splint-discuss] Q: Using splint in development of new code. References: <20030325212448.72959.qmail@web12306.mail.yahoo.com> Message-ID: <3E80E0B2.E93CA267@yahoo.com> Austin Hastings wrote: > > I'm considering using splint for a large-scale open-source development > effort that is currently in very early development, although a fair > chunk of code has been written. > > This means that there's going to be a lot of code coming in, and most > of it, initially, won't be annotated. (And some more, naturally, won't > be annotated correctly.) > > Has anyone written an "annotation primer" that is a one or two page > distillation of the splint manual? > > I'm envisioning something like this: > > When you're doing this: Annotate thus: > > - returning the only copy /*@only@*/ > of a data item > > - temporarily using a data /*@temp@*/ > item but not taking > responsibility for it > > Maybe with more info, or less. IMO you are taking the wrong path. The problem is not how to shut splint (or your compiler) up about unsound constructs, but to avoid those constructs in the first place. I keep three aliases for splint around, called splintwk, splintit, and splint, in increasing order of severity. splintwk is just splint -weak. splintit is customized to my comfort level. I don't believe in any annotations, but bear in mind that warnings are just that, not errors. If you do annotate they should be accompanied by comments explaining why they are alright, because they probably won't in another revision. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! From austin_hastings at yahoo.com Wed Mar 26 00:33:15 2003 From: austin_hastings at yahoo.com (Austin Hastings) Date: Wed Mar 22 17:10:03 2006 Subject: [splint-discuss] Q: Using splint in development of new code. In-Reply-To: <3E80E0B2.E93CA267@yahoo.com> Message-ID: <20030326053315.28094.qmail@web12307.mail.yahoo.com> --- CBFalconer wrote: > Austin Hastings wrote: > > > > I'm considering using splint for a large-scale open-source > development > > effort that is currently in very early development, although a fair > > chunk of code has been written. > > > > This means that there's going to be a lot of code coming in, and > most > > of it, initially, won't be annotated. (And some more, naturally, > won't > > be annotated correctly.) > > > > Has anyone written an "annotation primer" that is a one or two page > > distillation of the splint manual? > > > > I'm envisioning something like this: > > > > When you're doing this: Annotate thus: > > > > - returning the only copy /*@only@*/ > > of a data item > > > > - temporarily using a data /*@temp@*/ > > item but not taking > > responsibility for it > > > > Maybe with more info, or less. > > IMO you are taking the wrong path. The problem is not how to shut > splint (or your compiler) up about unsound constructs, but to > avoid those constructs in the first place. > I hadn't considered that /*@only@*/ and /*@temp@*/ were ways to shut splint up, but rather ways to give it more information so it could do stronger checking. My objective is to make it as simple as possible for large numbers of developers who are not familiar with splint to ramp up quickly to maybe 90% of all annotations. Things like knowing exactly the annotation for malloc/free and friends I'm willing to let go by on the "initial pass". =Austin > I keep three aliases for splint around, called splintwk, splintit, > and splint, in increasing order of severity. splintwk is just > splint -weak. splintit is customized to my comfort level. I > don't believe in any annotations, but bear in mind that warnings > are just that, not errors. If you do annotate they should be > accompanied by comments explaining why they are alright, because > they probably won't in another revision. From stephane.martin at ca.kontron.com Wed Mar 26 11:29:55 2003 From: stephane.martin at ca.kontron.com (=?iso-8859-1?Q?=22Martin=2C_St=E9phane=22?=) Date: Wed Mar 22 17:10:03 2006 Subject: [splint-discuss] Q: Using splint in development of new code. Message-ID: <5009AD9521A8D41198EE00805F85F18F03A86504@sembo111.teknor.com> >My objective is to make it as simple as possible for large numbers of >developers who are not familiar with splint to ramp up quickly to maybe >90% of all annotations. Things like knowing exactly the annotation for >malloc/free and friends I'm willing to let go by on the "initial pass". I agree with that, if you try to run full Splint Check at the first time you will throw away Splint because there will be just to much warning. I also agree that you must lurn how to use Splint when it is included in the developpement tools wich is not always obvious when you work with a developpement team. My guess is to use Splint with fery few checking at the begining when inserting it on the developpement tool of a project and from day to day to add more checks. From evans at cs.virginia.edu Wed Mar 26 11:45:01 2003 From: evans at cs.virginia.edu (David Evans) Date: Wed Mar 22 17:10:03 2006 Subject: [splint-discuss] Q: Using splint in development of new code. In-Reply-To: <20030325212448.72959.qmail@web12306.mail.yahoo.com> References: <20030325212448.72959.qmail@web12306.mail.yahoo.com> Message-ID: On Tue, 25 Mar 2003, Austin Hastings wrote: > ... > Has anyone written an "annotation primer" that is a one or two page > distillation of the splint manual? > ... The closest thing we have now to a very short introduction to using Splint is an assignment from the intro software engineering course I teach: http://www.cs.virginia.edu/cs201j/problem-sets/ps6/ This assignment was intended for students who had not programmed in C before either, so it is not what you would want to use for experienced developers, but it does include short descriptions and examples of /*@abstract@*/, /*@null@*/ and /*@only@*/ annotations. Given that different applications will want to use different checks, I'm not sure if there is a generic short document that works for everyone. The chapters of the Splint Manual are intended to be mostly standalone, so that after you read Chapter 1, then you can skip around the other chapters depending on what type of checking is most important for your development. --- Dave From sidprice at softtools.com Thu Mar 27 12:08:45 2003 From: sidprice at softtools.com (Sid Price) Date: Wed Mar 22 17:10:04 2006 Subject: [splint-discuss] Win32 File and Path anmes Message-ID: <00f201c2f483$880fb8a0$27cfed89@sc021077> Hello, I have just started to try and setup Splint to work with Embedded Visual C under Windows 2000 and I am having trouble setting up the include paths. Does Splint support spaces in paths and filenames please? If so what is the syntax for the "+I" option? Thanks Sid. Sid Price's Software Tools http://www.softtools.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cs.Virginia.EDU/pipermail/splint-discuss/attachments/20030327/b0196551/attachment.htm