Subject: Re: How do I treat a symbol table? - msg#00049

Previous Message by Date: click to view message preview

Re: Loops over pointers

On Wednesday 24 August 2005 08:19 am, Tommy Pettersson wrote: > On Wed, Aug 24, 2005 at 03:17:36PM +0200, akarl wrote: > > By default Splint also complains about statements like > > > > if (n) { ... } > > > > where n is an int, whereas > > > > if (n != 0) { ... } > > > > is OK. This behavior can be changed with the predboolint option. Maybe > > we are looking for a predboolptr option here. > > The pred-bool-ptr option exists and muffles > > if (ptr) > > and > > if (!ptr) > > but it doesn't convince splint that ptr really is or isn't > NULL for some mysterious reason. Bug or not, I think it would > be great if it did so, although thinking won't change splint... Actually, the above isn't quite correct -- splint IS convinced that ptr really is NULL for if() and while() -- just not for for(). For example, in: ============= // test of splint problem // structure type typedef struct node node; struct node { /*@null@*/node *next; int value; }; node *first; /*@-predboolptr@*/ int look_for_value(int val) { node *n; // coded as a for() loop -- splint complains for (n = first; n; n = n->next) { if (n->value == val) return 23; } // coded as a while() loop -- splint is happy n = first; while (n) { if (n->value == val) return 23; n = n->next; } // coded as an if() test -- splint is happy n = first; loop: if (n) { if (n->value == val) return 23; n = n->next; goto loop; } return 0; } ====== splint complains about the 'n->value' in the for() loop, but not in the if() or while() loops: =========== ~/splint$ splint -exportlocal test2.c Splint 3.1.1 --- 21 Aug 2005 test2.c: (in function look_for_value) test2.c:21:14: Arrow access from possibly null pointer n: n->value A possibly null pointer is dereferenced. Value is either the result of a function which may return null (in which case, code should check it is not null), or a global, parameter or structure field declared with the null qualifier. (Use -nullderef to inhibit warning) test2.c:19:30: Storage n may become null Finished checking --- 1 code warning ========== This seems clearly to be a bug. I have copied splint-bug to amend my earlier report of this problem. -- Terry Terry Colligan terry-splint-cUjd5OYHpVRWk0Htik3J/w@xxxxxxxxxxxxxxxx

Next Message by Date: click to view message preview

Re: Loops over pointers

Tommy Pettersson wrote: On Wed, Aug 24, 2005 at 03:17:36PM +0200, akarl wrote: By default Splint also complains about statements like if (n) { ... } where n is an int, whereas if (n != 0) { ... } is OK. This behavior can be changed with the predboolint option. Maybe we are looking for a predboolptr option here. The pred-bool-ptr option exists and muffles if (ptr) and if (!ptr) but it doesn't convince splint that ptr really is or isn't NULL for some mysterious reason. Bug or not, I think it would be great if it did so, although thinking won't change splint... OK, then it's most certainly a bug. August

Previous Message by Thread: click to view message preview

Re: How do I treat a symbol table?

On Tuesday 23 August 2005 11:07 am, Tommy Pettersson wrote: > On Tue, Aug 23, 2005 at 10:02:37AM -0700, Terry Colligan wrote: > > One of my problems is how to treat a symbol table. I need > > mostly to add malloc'd copies of strings to the symbol table, > > but the symbol table is initialized with some string literals. > > > > The code: > [...] > > I looks like you aren't planning to release any of the memory > owned by the symbol table, since you add pointers to string > literals to it with no special markings. That's currently true, but I could add two routines -- one for static string literals, and one for malloc'd strings. > Then it doesn't make so > much sense to track the release responsibility (with /*@keep@*/ > et.al.). I got sucked into using /*@keep@*/ because of the situations where the stored string was, in fact, dynamically allocated. I need an annotation-based solution, rather than a flag-based solution, because I don't want to lose the checking for other dynamically-allocated pointers. > I think there are some splint markups for garbage > collection drive memory handling, so pointers can be used freely > but not for releasing the memory. I have never tried it, I'm not > sure my memory serves me right, and I don't have time to look it > up now, sorry. It's just an idea, not necessarily a good one. I found what you mentioned: the 'shared' attribute. Changing the 'keep' attribute to 'shared' seems to solve this problem. Thanks to Tommy and to Luke Imhoff, who also suggested 'shared' attribute. -- Terry Terry Colligan terry-splint-cUjd5OYHpVRWk0Htik3J/w@xxxxxxxxxxxxxxxx

Next Message by Thread: click to view message preview

RE: How do I treat a symbol table?

I think /*@share@*/ is the recommended garbage collected annotation. -----Original Message----- From: splint-discuss-bounces-PtzpWEKHOf7sOVejVcbrAg@xxxxxxxxxxxxxxxx [mailto:splint-discuss-bounces-PtzpWEKHOf7sOVejVcbrAg@xxxxxxxxxxxxxxxx] On Behalf Of Tommy Pettersson Sent: Tuesday, August 23, 2005 1:07 PM To: splint-discuss-Y5+ky9gHf7K61byRX2g7jjevRRvlBcP1@xxxxxxxxxxxxxxxx Cc: terryc-cUjd5OYHpVRWk0Htik3J/w@xxxxxxxxxxxxxxxx Subject: Re: [splint-discuss] How do I treat a symbol table? On Tue, Aug 23, 2005 at 10:02:37AM -0700, Terry Colligan wrote: > One of my problems is how to treat a symbol table. I need > mostly to add malloc'd copies of strings to the symbol table, > but the symbol table is initialized with some string literals. > > The code: [...] I looks like you aren't planning to release any of the memory owned by the symbol table, since you add pointers to string literals to it with no special markings. Then it doesn't make so much sense to track the release responsibility (with /*@keep@*/ et.al.). I think there are some splint markups for garbage collection drive memory handling, so pointers can be used freely but not for releasing the memory. I have never tried it, I'm not sure my memory serves me right, and I don't have time to look it up now, sorry. It's just an idea, not necessarily a good one. -- Tommy Pettersson <ptp-SamgB31n2u5IcsJQ0EH25Q@xxxxxxxxxxxxxxxx> _______________________________________________ splint-discuss mailing list splint-discuss-Y5+ky9gHf7K61byRX2g7jjevRRvlBcP1@xxxxxxxxxxxxxxxx http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss