Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!lll-lcc!pyramid!voder!kontron!cramer
From: cramer@kontron.UUCP (Clayton Cramer)
Newsgroups: comp.lang.c
Subject: Re: Passing (char *) NULL to printf to match %s
Message-ID: <1774@kontron.UUCP>
Date: Mon, 10-Aug-87 21:02:20 EDT
Article-I.D.: kontron.1774
Posted: Mon Aug 10 21:02:20 1987
Date-Received: Wed, 12-Aug-87 02:31:11 EDT
References: <166@qetzal.UUCP> <157@hobbes.UUCP> <875@bsu-cs.UUCP> <1219@cognos.UUCP>
Organization: Kontron Electronics, Mt. View, CA
Lines: 21

> In article <875@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
> ! I believe that the interpretation of (char *) NULL when supplied as the
> ! actual parameter where printf is looking for a string may have changed
> ! over the years.  The "correct" behavior today, according to ANSI C as
> ! I know it, is for printf to print a token signifying that a NULL
> ! pointer was passed.  Microsoft C will print the string "(null)" when
> ! this happens.  However my System V Release 2 manual as supplied with
> 
>   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)".
> -- 
> Brian Campbell          uucp: decvax!utzoo!dciem!nrcaer!cognos!brianc

I would love to know how you get a string at DS:0 with Microsoft C --
they reserve something like 16 bytes starting at DS:0 so that at end of
job, they can check for nil pointer reference writes by checking to
see if any of these bytes have been altered.

Clayton E. Cramer