🚀 go-pugleaf

In article <4i6fn8$p0g@solutions.solon.com>, "Christian.DESTOR" <Christian.DESTOR@ln.cit.alcatel.fr> writes:
> Hi, 
> We ara willing to provide to our C programmers a sort of check-list they could
> use for self-controlling their code.
> Could anyone give me reference about already existing lists.
> I know also that books have been published about traps and pitfalls in C.
> but I don't have the exact references.
> Thank you in advance

Hoola, either the programmers won't read the list or you need to consider
a new team.

But here is one simple rule,  always use (Type*)0 and not null for null 
pointer check.  Show my a thousand standards that say I don't need 
to do that, I would still use the construct.

Anh

In article <4i97jv$8hn@solutions.solon.com> ANH@KUHUB.CC.UKANS.EDU writes:
>But here is one simple rule,  always use (Type*)0 and not null for null 
>pointer check.  Show my a thousand standards that say I don't need 
>to do that, I would still use the construct.
>
>Anh

I'll byte, what exactly does (Type*)0 do that NULL doesn't do and why will
it always work whereas NULL may or may not?

Angelo
-- 
Old Programmers Never Die ... They Just Lose Their Bits

In article <4ian7m$h54@solutions.solon.com>,
Angelo John Mileto <runner!amileto@uunet.uu.net> wrote:
:In article <4i97jv$8hn@solutions.solon.com> ANH@KUHUB.CC.UKANS.EDU writes:
:>But here is one simple rule,  always use (Type*)0 and not null for null 
:>pointer check.  Show my a thousand standards that say I don't need 
:>to do that, I would still use the construct.
:>
:>Anh
:
:I'll byte, what exactly does (Type*)0 do that NULL doesn't do and why will
:it always work whereas NULL may or may not?

Actually....

	printf( "%p\n", (void*) NULL); /* OK */
	printf( "%p\n", (Type*) NULL); /* not OK */
	printf( "%p\n",  NULL);        /* not OK */

(Same if 0 is used rather than NULL in any of these.)

(See 4.9.6.1.)

Cheers,
Stan.
--
Stan Ryckman  (stanr@tiac.net)
  (Apologies for non-responses or late responses to some posts;
  .newsrc was trashed and I'm trying to get it back to where it was.)

In article <4ian7m$h54@solutions.solon.com> runner!amileto@uunet.uu.net (Angelo John Mileto) writes:
>In article <4i97jv$8hn@solutions.solon.com> ANH@KUHUB.CC.UKANS.EDU writes:
>>But here is one simple rule,  always use (Type*)0 and not null for null 
>>pointer check.  Show my a thousand standards that say I don't need 
>>to do that, I would still use the construct.
>>
>>Anh
>
>I'll byte, what exactly does (Type*)0 do that NULL doesn't do and why will
>it always work whereas NULL may or may not?
>
Consider a machine where a (char *) and an (int *) are not the same
(Honeywell DPS/6 for example), and a function written with the old K&R
style.  Then you always needed to cast your NULL pointers to get them
into the right size/format for the called function.  I used to keep
arround a macro for just this

#define Nullp(type) ((type *)NULL)

All this changed with ANSI C and prototypes.  By using protypes
instead I can just code NULL, and the explicit cast is no longer
needed.  I find it a better technique.  I no longer routinely liter
code with casts.  This reduces clutter in the code and make the
remaining casts stand out as something special.


Summary.  Prior to ANSI C and prototypes, coding (type *)0 was
a useful practice.  It has been superceded by changes in the language
and is no longer particularly good style.

[Except, of course, in variadic function argument lists. -mod]

In article <4ietaq$b0n@solutions.solon.com>, stanr@tiac.net (Stan Ryckman) writes:
 > In article <4ian7m$h54@solutions.solon.com>,
 > Angelo John Mileto <runner!amileto@uunet.uu.net> wrote:
 > :In article <4i97jv$8hn@solutions.solon.com> ANH@KUHUB.CC.UKANS.EDU writes:
 > :>But here is one simple rule,  always use (Type*)0 and not null for null 
 > :>pointer check.  Show my a thousand standards that say I don't need 
 > :>to do that, I would still use the construct.
 > :>
 > :>Anh
 > :
 > :I'll byte, what exactly does (Type*)0 do that NULL doesn't do and why will
 > :it always work whereas NULL may or may not?
 > 
 > Actually....
 > 
 > 	printf( "%p\n", (void*) NULL); /* OK */
 > 	printf( "%p\n", (Type*) NULL); /* not OK */
 > 	printf( "%p\n",  NULL);        /* not OK */
 > 
 > (Same if 0 is used rather than NULL in any of these.)
 > 
 > (See 4.9.6.1.)
 > 
 > Cheers,
 > Stan.
 > --
 > Stan Ryckman  (stanr@tiac.net)
 >   (Apologies for non-responses or late responses to some posts;
 >   .newsrc was trashed and I'm trying to get it back to where it was.)

Really?  Seems like I need to update my 'beliefs' :-)  Actually, (TYPE*)0
has been recommended to me by several professors of mine who worked as
software engineer as places such as Bell Labs.

Just to re-iterate,

tMyType *ptr;
if (ptr==NULL) {
	... 
}

is a perfectly safe construct?

[Yes, and in fact, so is
	if (ptr == 0)
 and it is guaranteed equivalent. -mod]

Anh

In article <4imak1$e0j@solutions.solon.com>
ANH@KUHUB.CC.UKANS.EDU writes:
<snip>
A:  > 	printf( "%p\n", (void*) NULL); /* OK */
A:  > 	printf( "%p\n", (Type*) NULL); /* not OK */
A:  > 	printf( "%p\n",  NULL);        /* not OK */
<snip>
A: Really?  Seems like I need to update my 'beliefs' :-)  Actually, (TYPE*)0
A: has been recommended to me by several professors of mine who worked as
A: software engineer as places such as Bell Labs.

I think that the basic problem is that there is actually no
alternative to learning a language: such rules of thumb are often
misleading. %p needs a pointer of type void*, and unless Type is same
as void, (Type*)NULL is not such a pointer. In a prototyped function
which specifies void* as a parameter type, (Type*)NULL will be
converted to void*. printf is not such a function. So, passing
(Type*)NULL to printf is plain wrong (when the format specifies %p
that is).

Note, however, that this has nothing to do with NULL, (void*)NULL and
(Type*)NULL have different types, and one may need one or the
other. The usual mistake is, in fact,
Type x;
printf( "%p\n", &x); /* wrong */
printf( "%p\n", (void*) &x); /* OK */

Plain NULL is wrong because of a similar reason. In fact, NULL is not
guaranteed to have a pointer type at all. The only useful thing that
is guaranteed is that when cast, compared, passed as a visibily
prototyped parameter or assigned to a pointer (let's not get technical
with the actual wording here: it is not comp.std.c), NULL becomes a
null pointer of appropriate type. None of these applies in the current
situation, and so use of unadorned NULL is incorrect.

A: 
A: Just to re-iterate,
A: 
A: tMyType *ptr;
A: if (ptr==NULL) {
A: 	... 
A: }
A: 
A: is a perfectly safe construct?

Yes, see the last para.

A: 
A: [Yes, and in fact, so is
A: 	if (ptr == 0)
A:  and it is guaranteed equivalent. -mod]
A: 
A: Anh
--
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]

ANH@KUHUB.CC.UKANS.EDU wrote:

> > :>But here is one simple rule,  always use (Type*)0 and not null for null 
> > :>pointer check.  Show my a thousand standards that say I don't need 
> > :>to do that, I would still use the construct.
> > :
> > :I'll byte, what exactly does (Type*)0 do that NULL doesn't do and why will
> > :it always work whereas NULL may or may not?
> > 

[snip]

> Actually, (TYPE*)0
>has been recommended to me by several professors of mine who worked as
>software engineer as places such as Bell Labs.

I think the reason for this is because (void *) NULL is the correct
way to terminate a null terminated variable argument list, just using
NULL will not work on some compilers. (So I've heard anyway, I have 
never used one of these compilers)

Niall