Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!think!husc6!seismo!nbires!vianet!devine
From: devine@vianet.UUCP
Newsgroups: comp.lang.c
Subject: Re: Writing readable code
Message-ID: <197@vianet.UUCP>
Date: Tue, 7-Jul-87 23:05:23 EDT
Article-I.D.: vianet.197
Posted: Tue Jul  7 23:05:23 1987
Date-Received: Sat, 11-Jul-87 15:39:20 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <13148@topaz.rutgers.edu>
Organization: Western Digital, Boulder Tech Ctr
Lines: 18
Summary: fact about MS C

In article <13148@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes:
> Microsoft C (if it really requires NULL to be 0L) is broken by all
> standards that C compilers have ever been designed to.  K&R explicitly
> defined 0 comparisons to pointers to be the rule and no one since has
> come up with any convincing arguments to the contrary.

  Yes, MS does define NULL to be 0L for large model programs.  It is
correctly set to the integer constant 0 for small and medium models.
The error is compounded by having NULL #define'd like that in *several*
include files -- not just stdio.h.

  That split definition comes from the MS decision [*] to support its
linker.  This thinking also created the atrocity of "near" and "far" pointers.

Bob Devine

[*] It also may be argued that this all stems from Intel's decision to be
    forever backward-compatible with an old chip design.