🚀 go-pugleaf

In article <1992Dec14.225659.24225@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>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.

	Why not?
>
>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?

	ptrcmp is standard, required function, it must yield a total
	order.

	No dichotomy. ptrcmp is mandatory.

	I'm not yet convinced it need bear ANY relation to
	==, !=, < etc on pointers.

	In that case it is implementable on all systems
	where (opinion follows, please correct errors)

	a) void* is big enough to hold all pointer types
	b) conversions always pad systematically
	c) bitwise comparison is done 
	d) the bits of a pointer cannot be magically changed by the system
	e) a pointer is implemented as an object in contiguous storage

c) ensures a total order by injective mapping of pointers to integers,
NOT necessarily long though.

b) ensures determinism

a) ensures ptrcmp(void*,void*) can be called without loss of bits

Such a function allows pointers to be, say, sorted, without any
expected correlation with the order of the objects they point to.

I am not sure of the wisdom or workability of having any additional
rules relating ==, < etc to ptrcmp.

>
>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.

	These 'lisp' machines must break rule (d) above then?

>
>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.

	I suggest the *actual* implementation be what is compared.

	Certainly, (e) might cause problems on the 80x86 where part of the
pointer is implicit and not physically stored. Does it *actually*
cause this problem?


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------