Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Comparison functions for qsort() and bsearch()
Keywords: Sun, C++
Message-ID: <70450@microsoft.UUCP>
Date: 4 Feb 91 20:42:25 GMT
References: <1991Jan9.161633.21922@clear.com> <1991Jan21.022720.20707@cbnewsk.att.com> <70271@microsoft.UUCP> <1991Feb3.195156.151@cbnewsk.att.com>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 42

In article <1991Feb3.195156.151@cbnewsk.att.com| hansen@pegasus.att.com (Tony L. Hansen) writes:
|Then it's a good thing that the ANSI C++ committee chose to use both the
|cfront 2.1 reference manual (which is essentially E&S) AND the ANSI C
|standard as their base documents.  Obviously there are a few things that are
|missing from the cfront 2.1 reference manual. If you use both documents,
|you'll find the necessary constraints. In fact, ANSI C (C S3.2.2.3) states
|explicitly:
|
|    A pointer to any incomplete or object type may be converted to a pointer
|    to void and back again; the result shall compare equal to the original
|    pointer.
|
|Another place (C S3.1.2.5) makes the guarantee that a void* and char* must
|have the same respresentation and alignment requirements.  Nothing in E&S
|eliminates these requirements.  E&S does explicitly add (C++ S5.4) that a
|void* is an object pointer.
|
|I think this should calm down anyone's fears that you can't use a void* as
|the "generic pointer". However, the ANSI C++ committee definitely needs to
|combine both sets of constraints into the standards document which eventually
|comes out.
|
|Anyone implementing a C++ compiler cannot just look at E&S. It's the
|combination of that and ANSI C which will be the eventual standard, not just
|one.

Hanson's position is that one can assume that any permissions granted by
ANSI-C not granted by ARM represents an omission from ARM.  I disagree.
The ANSI-C++ committee's stated position is that the ARM is the primary
source, and the ANSI-C document is secondary.  This raises the question
of whether differences between ARM and the ANSI-C document are intentional,
or accidental.  These differences will hopefully, someday, be resolved by
the ANSI-C++ committee.  Until then, someone wanting to write portable
C++ code would do well to only write code to the explicit permissions
contained in ARM.

There are already, well documented, well thought out, differences between
ANSI-C and C++ in regards to void pointers.  I see no reason to assume then,
in this case, that ANSI-C and C++ will be the same.  Again, I encourage
people to consider ARM and the working papers of the ANSI-C++ committee
to be the defacto definition of C++ until we get the final ANSI-C++ document
some years hence.