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

Text File | 1992-12-21 | 3.9 KB | 89 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: Sun, 20 Dec 1992 01:25:51 GMT
Lines: 76

In article <[e-mail]> [e-mail] (James Kanze) writes:
>In article <[e-mail]>
>[e-mail] (John MAX Skaller) writes:
>|> >different addresses, but are pointing to the same object, must they
>|> >compare equal?
>
>|>     The answer to this particular question is YES, they must
>|> compare equal according to the ARM. And I think this is a problem
>|> for OS design for the 386, for example, where the memory management
>|> kernel will just have to ignore the ARM.
>
>As it should.  The ARM (and the upcoming ANSI standard) can only
>address what happens in the context of C++, not what happens to the
>pointer once the OS gets its hands on it.

    No, this is not true IMHO. The ARM can and does explicitly
or implicitly say "implementation defined" where it means that.
When the ARM says "so and so will be the case" then it must
always be the case.

>
>In a similar vein, for example, the ANSI C standard states that the
>NULL pointer will not point to any object.  But all 8086 programmers
>know that if you compile with 32 bit pointers, it actually points to
>the interrupt vector table!  However, this is *not* an object defined
>in any C program, so this is perfectly legal.  (If it wasn't, you
>couldn't have C on machines without protected memory.)

    This is just your interpretation that "object"
means "object created by the program". It should not
be up to your interpretation IMHO.

>
>In the same way, I would understand the ARM to be saying that all
>pointers generated by a correct program to point to any object defined
>(including a dynamic definition by new) in C++ will compare equal.  If
>you give the pointer to the OS, and it gives it back to you, then any
>guarantees must be made by the OS, and not the C++ language.

    I agree. But that is not the case. The ARM says different.
It absolutely requires pointers to the same object to compare
equal, without qualification. The system MUST ensure this
to classify as conforming. Since we both agree this is undesirable,
as it would make conforming translators impossible to write,
we have to change the ARM (well, the standard) to say what we
actually mean.

>|>     If we dropped this requirement, however, there would
>|> be no easy way to identify objects.
>
>Once you leave the safe and easy world of your program, there is no
>easy way to identify objects.  C++ doesn't address such problems as
>persistance, transportability or shared memory.

    It doesnt have to if it leaves enough things
"implementation defined". If something is "ARM defined",
it isnt implementation defined, and the translator MUST
do what the ARM says to be ARM-conforming. Similarly,
if it is one of those things the translator CANT be
responsible for, a strictly conforming program must
follow those rules. (E.g. not pointing more than 1 past
the end of an array).

    The problem then is that it isnt possible
to write a C++ program to do 386 memory management
with the current rule for == for pointers.
Not even a non-stricty conforming one, because there is no
scope for implementation defined variation.

    IMHO there should be.

--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------