🚀 go-pugleaf

In article <1992Dec12.154918.2220@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|which cannot break existing implementations but provides a  total
|order by way of a library function? If so, can we put this to
|the library WG?

I think some flavor of "ptrcmp" makes sense on those implementations that
support casting pointers to integrals and back, and probably doesn't make
sense on those implementations that don't support the pointer/integral casts.

In either case, I would ask what kind of sense it makes to write a "standard"
that *requires* a certain behavior of *some* implementation but doesn't
*require* that behavior of *all* implementations?  How do you justify such
a dichotomy?

On the contrary, I suggest that in a "standard" either something IS *required*
of *all* implementations, or something IS NOT *required* of *all* 
implementations.  If the committee cannot agree that something IS or IS NOT 
*required* of all implementations, then what they should do instead is list 
this something as a "commonly implemented extension to the language."

Such would be the proper designation, IMHO, for both the bidi pointer/integral
cast, and for the proposed "ptrcmp" macro.  Then, on Lisp machines, or 
C++ OODBMS's or whatever systens would find the total ordering 
practically unsupportable in their environment, they simply would not implement
the "common extension."  This would be a quality of implementation issue then,
not an issue of conformance.

In any case, "ptrcmp" would be a misnomer, because what is being compared
is *not* pointers, but rather the underlying *assumed* implementation of 
pointers using machine addresses.  The correct name might be something like 
"addrcmp" then, so as to not further confuse programmers on the difference
between language and implementation.