uustatus - realtime uustat for HDB uucp (w/findpath)

[Greg Woods]

In article <13048 at steinmetz.ge.com> davidsen at crdos1.UUCP (bill davidsen) writes:
> In article <1989Jan30.013936.11995 at gpu.utcs.toronto.edu> woods at gpu.utcs.Toronto.EDU (Greg Woods) writes:
[That's me!]
> | 
> | What I'm about to say is really just a flame, but at the same time, I
> | don't want to start a war either.  This is posted, instead of being
[The war's on!  :-)]
> | mailed, out of general frustration at a very obvious mis-understanding
> | that has perpetuated itself for far too long.
> 
>   What I am going to say is a flame, too. The ANSI standard for C says
> that NULL will return a pointer constant. Not an integer constant,
> *pointer*. Section 4.1.5, line 4, page 96. Please stop posting your
> opinion as fact. What you mean is that K&R used NULL and you wish it
> hadn't changed. Anyone who writes portable code never assumes integet
> *or* pointer, but casts it as needed and uses zero when they mean zero.

As I said to someone whom I did provide my evidence to:  I don't have a
copy of the ANSI standard.  However, I have read T. Plum's summary, and
find in it a clear statement that confirms that zero is still legal when
used to compare or assign null pointers.  He also mentions that NULL
should be defined as zero, although (void *)0 is accepted.  In MY
opinion, NULL defined as zero cast to a pointer is only acceptable when
(sizeof(int) == sizeof(void *)) is true.

> | [...]
> 	Correct! Older programs which used NULL as if it were zero will
> fail under ANSI compilers. So will Pascal programs. They are not 100%
> compatible, although it is possible to write in that set of features
> shared by K&R and ANSI.

Actually, they won't, unless the programme, or the compiler suppiled
header files define NULL as something other than zero.

In Unix land, are they ALL old programmes?  1/2 :-)

> 	The effect of pointer-int is well defined, which is what I
> assume you mean. NULL is treated as an address, which will cause strange
> side effects if you think it's an int (and also if you think that a zero
> should be treated as an address).

NO, I know all about pointer-int problems....
But pointer-int comparisons are NOT the same as pointer-zero comparisons.
Pointer-zero comparisons are what you are supposed to be able to do to
identify null pointers.

> 	Your assumption that NULL was zero in K&R C (1st ed) is correct,
> and 2nd ed. could be read to say that, although their explanation (pg
> 102) states assignment and comparison with pointers. In the assumption
> that NULL is incorrect if defined as a pointer, you are obviously in
> conflict with the ANSI standard.

As a Unix fan, I don't give a hoot about ANSI C, and I won't until I
have to use an ANSI C compiler from AT&T. :-)

> 	In my opinion any code which assumed the type of NULL as either
> int or pointer will break on some machine.

I NEVER assume the type of NULL, though it is nice to have it defined as
something which is the width of an int (being that all args to functions
are at least that wide after the "usual conversions" are applied).  I
always cast NULL to the appropriate type of pointer when using it as an
argument, but I NEVER want to have to cast it for an assignment, nor
for a comparison.

What I despise are compilers that cannot find
'(some_pointer_variable_that_is_null == 0)' as true.  My original faith
in compilers was shattered by one such broken piece of junk.  It wasn't
that I'd never experienced a compiler bug before, but to have something
so fundamental to the language break in some contexts, but not others
really tore me up.
-- 
						Greg Woods.

{utgpu,lsuc!gate,ontmoh}!woods, woods@{gpu.utcs.Toronto.EDU,utorgpu.BITNET}
1-416-443-1734 [h], 1-416-595-5425 [w]   LOCATION: Toronto, Ontario, Canada