use of NULL

Clayton Cramer cramer at optilink.UUCP
Wed Feb 22 08:33:40 AEST 1989


In article <16020 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
> >In article <9582 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
> >>Using 0 instead of NULL is perfectly acceptable.
> 
> In article <965 at optilink.UUCP> cramer at optilink.UUCP (Clayton Cramer)
> substitutes too many `>'s (I patched the references line) and writes:
> >No it isn't.  Segmented architecture machines will have problems with
> >that in large model.  Microsoft defines NULL as 0L, not 0, in large
> >model.  Pushing an int 0 instead of a long 0 will screw you royally
> >on the PC.
> 
> Doug Gwyn is right; you are reading things into his posting that
> are not there.  Using 0 wherever NULL is strictly legal will always
> work.  Never mind the fact that, by trickery, Microsoft C defines NULL
> in a way that works for INCORRECT calls in large model (but *not* for
> medium nor compact models), as a concession to bad programmers' wrong
> programs.

This is not correct.  Microsoft C defines NULL in a way that works
for CORRECT calls in large model, and in medium and compact models.

"Using 0 whereever NULL is strictly legal" will not work in Microsoft
C, and because Microsoft has come up with the correct solution for
an otherwise damaged architecture.  Chris' additional comments make 
a distinction between data and code pointers.  This will be a problem
in compact and medium models (only), as described on page 142, 
section 6.3.3 of the "Microsoft C Optimizing Compiler User's Guide":

    Note that in medium and compact models, NULL must be used
    carefully in certain situations.  NULL actually represents
    a null data pointer.  In memory models where code and data
    pointers are the same size, it can be used with either.  
    However, in memory models where code and data pointers are
    different sizes, this is not the cas.  Consider the 
    following example:

And they show a similar example to Chris.  Note that they have
erred on the side of screwing up code pointers, not data pointers,
since data pointers are FAR more common in C than code pointers.

Note also that most programs of any great complexity end up in
large model on the PC, not medium or compact.


    
-- 
Clayton E. Cramer
{pyramid,pixar,tekbspa}!optilink!cramer
Disclaimer?  You must be kidding!  No company would hold opinions like mine!



More information about the Comp.lang.c mailing list