Path: utzoo!utgpu!cunews!cognos!jimp
From: jimp@cognos.UUCP (Jim Patterson)
Newsgroups: comp.lang.c
Subject: Re: the nil pointer is not zero
Message-ID: <9070@cognos.UUCP>
Date: 21 Nov 90 19:38:41 GMT
References: <s64421.658489804@zeus> <27636@mimsy.umd.edu> <164@nazgul.UUCP> <14516@smoke.brl.mil> <171@nazgul.UUCP> <6205@quanta.eng.ohio-state.edu>
Reply-To: jimp@cognos.UUCP (Jim Patterson)
Organization: Cognos Inc., Ottawa, Canada
Lines: 60

In article <6205@quanta.eng.ohio-state.edu> rob@mowgli.eng.ohio-state.edu (Rob Carriere) writes:
>In article <171@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
>>In article <14516@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>>/I don't think so.  What good would it do you to know how a null pointer
>>/is represented?  There is nothing useful you can do about that.
>>
>>2. You will be able to reliably be able to use memset and calloc to initialize
>>   structures containing pointers.
>
>Again, true.  But isn't this a sepcification bug, rather than a langauage bug?
>I think we need a function that can realiably initialize structures containing
>pointers, floats, doubles and long doubles; I don't think we should hack the
>language instead.

But how can you write such a function, for the GENERAL case, without
"hacking the language"? I wouldn't call it "hacking the language"
though to specify what the value of a NULL pointer is, instead of
leaving it "unspecified". If there's a "specification bug", I think
this is it.  While I can understand why ANSI made the choice they did,
it's still hard to justify NOT using memset given the rarity of
machines which don't equate "NULL" with "all-bits-zero" at the
hardware level.

The C runtime environment simply doesn't provide the information
necessary to write a more general initialization function than memset,
meaning you either use "memset" (if it works), or you write specific
initialization code for each structure (and unless you do both, you'll
leave slack bytes uninitialized).  Also, you need tagged unions if you
want to handle union initialization correctly.

I'm all for using memset because it's reliable (no chance of missing
a field in the initialization, unless you miss the whole thing). I
dread the day that I have to port code to a Symbolics Lisp machine
though (:^).

Here's an alternative proposal, maybe for the next round of C
standardization.  In the same way that C allows a cast of 0 to a
pointer type, it could allow a cast of 0 to a struct or union type
and interpret it as being default-initialized value for that object.
This may seem like a hack, but in fact it's no more of a hack than the
same cast of a pointer value would be. (Except for the 0 special case,
it's an error to assign an integer to a pointer just as it's an error
to assign an integer to a struct).  This proposal would allow you to
initialize any struct or union by an assignment e.g.

   struct A { int b; char* c; double d} x;
   ...
   x = (struct A)0;

You can do the same thing already if you declare static default
initializers for all struct types and use them to provide default
initializations.  However, it's a lot more work; you have to adapt a
naming convention, ensure each one is declared on one-and-only-one
place, etc. A simple language construct like that above would be a lot
more convenient.
-- 
Jim Patterson                              Cognos Incorporated
UUCP:uunet!mitel!cunews!cognos!jimp        P.O. BOX 9707    
PHONE:(613)738-1440                        3755 Riverside Drive
NOT a Jays fan (not even a fan)            Ottawa, Ont  K1G 3Z4