Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: thanks for "down" answers
Message-ID: <9189@smoke.BRL.MIL>
Date: 15 Dec 88 20:27:57 GMT
References: <1886@loral.UUCP> <1082@goofy.megatest.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 30

In article <1082@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes:
>From article <1886@loral.UUCP>, by jlh@loral.UUCP (Physically Phffft):
>> I pointed out to him that wait wanted an address in which to 
>> stuff a result, and using 0 was probably not a good idea.  His 
>> reply was 'thats how it is in my manual', after a few minutes
>> of discussion it got upgraded to 'I tried it on my system and it 
>> works'. 
>Both perfectly valid and correct responces.

Well, not really.  First of all, the manual synopsis of the null-pointer
case is wrong, if you're talking about the 4.3BSD manual as your response
indicates.  In fact, Berkeley broke the non-null case too by changing
it from pointing to an int to pointing to a "union wait".  It should be
a pointer-to-int.  (This is specified as such in IEEE Std 1003.1-1988.)

The second point is, just because something happens to work does not
mean it has been done correctly.  Correct things work, but not the
converse.  Code that "works on my system" often stops working when
ported to another system, or even when a new compiler is installed.

>[Your instructor correctly casts the 0 to a pointer-type, which
>the manual omits.]

No, he INcorrectly cast it to a char* instead of an int* (or, to try
to follow the misdefinition in the 4.3BSD manual, a union wait*).

>To paraphrase Samuel L. Clemmons, I think that you will discover
>in couple of years that your instructors have learned quite a bit
>in the interim. :-)

But not enough, apparently.