Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!linus!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: What is wrong with this program?
Message-ID: <2606@sun.uucp>
Date: Sun, 11-Aug-85 16:33:22 EDT
Article-I.D.: sun.2606
Posted: Sun Aug 11 16:33:22 1985
Date-Received: Wed, 14-Aug-85 00:33:25 EDT
References: <117@graffiti.UUCP> <545@grkermi.UUCP>
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 55
> >
> >Sample output:
> >
> > tty03 /* This shows that data->ut_line isn't null */
> >bruce (null) 492299400 /* So what's the problem in this line? */
> Are you *sure* it really isn't null?
Yes, he's sure; "printf" prints "(null)" if the pointer it's handed is
itself null, not if it points to a null string. If the code posted was the
entire program, and not just a fragment, the problem is, as Chris Torek
pointed out, that the guy declared a pointer to the "utmp" structure, and
used it, without making it point to anything. He should just have declared
a structure and used it directly.
Confusion about structures and pointers to them seems to be common.
struct foo {
...
} bar;
struct foo *bletch = &bar;
is not necessarily better than
struct foo {
...
} bar;
and is more obscure (since the pointer isn't necessary, and the person
reading the code may waste time figuring out that fact). It may have some
benefit if 1) "bletch" is in a register, 2) you have addressing modes like
"short_displacement(Rn)", and 3) you *don't* have addressing modes like
"short_displacement(SP)" or "short_displacement(FP)" or the displacement of
the members of the structure from the SP or FP isn't "short". However, this
is uncommon (the PDP-11, VAX, M68000, Z8000 and CCI Power 6 families use a
general register as FP/SP, so it makes no difference; the NS32xxx family
supports the use of "displacement(FP)" in the same way it supports
"displacement(Rn)"; I suspect the WE32xxx family, and most of the other
machines out there do one or the other also; the 80*86 family looks like it
can with the proper choice of register to implement FP), and I'd be
surprised if it made enough difference to make the obscure code (which isn't
likely to run any faster on the machines mentioned above) worth it.
Nevertheless, I've seen this kind of thing often enough that I suspect it's
due to misunderstanding of C.
I've also seen code like that in the original article, where the user seems
to be under the impression that declaring a pointer automatically declares
something for it to point to *and* sets it to point to that - I've seen it
less, though, because it simply doesn't work.
Guy Harris