NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/std/cplus/1804

Text File | 1992-12-16 | 3.5 KB | 88 lines

Newsgroups: comp.std.c++
Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 16 Dec 1992 15:01:44 GMT
Lines: 75

In article <[e-mail]> [e-mail] (Jim Adcock) writes:
>In article <[e-mail]> [e-mail] (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,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------