Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!labrea!decwrl!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: Passing (char *) NULL to printf to match %s
Message-ID: <25173@sun.uucp>
Date: Sat, 8-Aug-87 20:15:52 EDT
Article-I.D.: sun.25173
Posted: Sat Aug  8 20:15:52 1987
Date-Received: Sun, 9-Aug-87 13:03:12 EDT
References: <166@qetzal.UUCP> <157@hobbes.UUCP> <875@bsu-cs.UUCP> <1219@cognos.UUCP>
Sender: news@sun.uucp
Lines: 22

>   Speaking of this... has anyone else noticed any problems with this in
> small model Microsoft C?  I seem to be unable to print out a string that
> happens to be placed at offset 0 of the data segment -- MSC's libraries
> decide it is a null pointer and format it as "(null)".

Either the representation of a null pointer in Microsoft C small
model is a pointer to offset 0 in the data segment, or it is not.  If
it is not, then there is a bug in their library; it is improperly
deciding that the pointer is null.

If it *is*, however (which I suspect it is), then a string that
"happens" to be placed at offset 0 of the data segment also "happens"
not to be a valid C object!  In a valid C implementation, *no* object
may have an address that compares equal to a null pointer.

Either Microsoft C allowed it to be placed there, in which case
*that* is the bug, or somebody got around whatever mechanism
Microsoft C provides to ensure that no C object gets put at that
location, in which case they got what they deserved.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com