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.