kanze@gabi-soft.de(?) wrote:
>> The reason that MS-DOS compilers wanted ((void*)0) was linked to the
>> different memory models.  Technically, passing NULL as a variadic
>> argument has never worked

I don't recall ever hearing that ((void*)0) was "wanted" by MS-DOS
compilers.  It does make things a little easier, though, for
compiler/library vendors to implement mixed-model variadic functions.

Preferring ((void*)0) over 0 (or 0L) leads to detection of more
pointer errors, which makes it a better choice for NULL.  C++,
unfortunately, has allowed that species of error to resurface again
because it mandates 0 (only) for NULL.  In addition, it created a
whole new species of pointer ambiguity (overloading) errors.

In any event, because of the headache that the different DOS memory
models created, the following never did work right on any of the DOS
C compilers I used:

    char near *  np;      /* 16-bit near pointer (offset) */
    char far *   fp;      /* 20-bit far pointer (seg+off) */

    fp = NULL;            /* => 0000:0000   */
    np = NULL;            /* => XXXX:0000   */
    fp = (char far *)np;  /* => XXXX:0000 ! */

    if (fp == NULL) ...   /* False! */

In other words, most DOS compilers didn't convert near null pointers
to far pointers correctly, leading to all sorts of annoying bugs.

Thankfully, mixed-model DOS programming has pretty much gone the way
of the dinosaur.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]