-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ralf
Wildenhues
Sent: 31 July 2003 12:49
To: [EMAIL PROTECTED]
Subject: [subs] Re: [splint-discuss] Newbie question
* Roland Illig wrote on Thu, Jul 31, 2003 at 01:05:43PM CEST:
> On Tue, Jul 29, 2003 at 12:16:52AM +0100, Kenny Stuart wrote:
> >
> > #include <stddef.h>
> >
> > /[EMAIL PROTECTED]@*/
> >
> > struct Tomato { int a, b, c; };
> > typedef /[EMAIL PROTECTED]@*/ /[EMAIL PROTECTED]@*/ struct Tomato* TOMATO;
> >
> > static TOMATO Tomato_create( void )
> > {
> > TOMATO tomato= (TOMATO)malloc( sizeof *tomato );
Two problems here: In C code, it is rather unfortunate to cast the
return value from malloc, as converting von 'void *' to any other
pointer type is valid without a cast (unlike C++). Moreover, the cast
usually hides compiler complaints when converting from (malloc being
implicitly declared as returning) int to a pointer type (which is a
bug!). Solution: #include <stdlib.h> above, and omit the cast here.
%%
Wow, I've not used 'C' for about 10 years, just started using it to take a
look at splint and totally forgot about implicit declarations, thanks for
the nudge, I just purchased a copy of ISO 9899/1999 for reference and see
implicit declarations have thankfully been removed, I like the fact you
don't need to explicitly cast from a null pointer to some other pointer type
for the reason you've given.
I'm not sure I would class conversion of an int to a pointer type as a bug
since it is described in the C99 standard as implementation defined, the way
I read it, although potentially non-portable, used properly it is likely to
yield the desired effect since the C99 standard (sorry, I've just purchased
the standard so I'm looking everything up, it'll wear off eventually ;)
further states that the mapping functions for converting a pointer to an
integer and vice versa are intended to be consistent with the addressing
structure of the execution environment, as my example code shows however,
it's easy (pre C99 at least) to do it accidentally, I won't be explicitly
casting null pointers again :)
> > if( tomato != NULL ) {
> > tomato->a= tomato->b= tomato->c= 0;
> > }
> tomato->a = 0;
> tomato->b = 0;
> tomato->c = 0;
Actually, these are potential NULL dereferences (assuming you meant them
to be after the closing brace.
%%
Ah, I see you've already mentioned that.
The original problem is kind of a limitation of splint[1], easily
circumvented by explicitly returning NULL in case the malloc failed.
%%
That's a surprise since it explicitly requires multiple return statements,
which as best practice suggests, I avoid wherever possible, huh, I was
convinced I'd lost my mind and was doing something fundamentally wrong!
Does anyone know if that's something that's likely to be addressed?
Thanks to all for the feedback, I've no doubt I'm going to be asking more
newbie questions as I progress so please bear with me ;)
Kenny.
_______________________________________________
splint-discuss mailing list
[EMAIL PROTECTED]
http://www.splint.org/mailman/listinfo/splint-discuss
