NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/std/cplus/1874

Text File | 1992-12-21 | 3.1 KB | 71 lines

Newsgroups: comp.std.c++
Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
From: [e-mail] (Fergus James HENDERSON)
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Computer Science, University of Melbourne, Australia
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 21 Dec 1992 11:31:18 GMT
Lines: 59

[e-mail] (John MAX Skaller) writes:

>[e-mail] (Jim Adcock) writes:
>>[e-mail] (John MAX Skaller) writes:
>>|But Jim, it is not implementation defined, it is required that
>>|pointers to the same object compare equal. It is therefore
>>|legal to have a function:
>>|
>>|    f(X* a, X*b) {
>>|    if(a==b) { /* special case, copy b object */ ... }
>>|    else *a+=*b;
>>|    }
>>|
>>However, if a strictly conforming implementation is presented with a
>>non-strictly conforming program, such as a program that calls OS
>>virtual memory mapping adjustment routines, or programs that send
>>pointers off the ends of arrays, or programs who don't properly point
>>at objects that correspond to the types of objects they pretend to point
>>at .... in all such cases all bets are off.
>>
>    I know what you are saying but dont see it.
>ARM p74:"two pointers to the same object compare equal".
>Any program for which this is not true cannot be conforming,
>neither strictly nor non-strictly, it is non-conforming, it is
>not in fact a C++ program.
>
>    Or have I got this wrong?

I think you have got this wrong.
Such a program might be neither strictly nor non-strictly conforming,
but it is still a C++ program, at least in as far as that term is
commonly used.

>    For this reason I think the ARM requirement is unworkable,
>and must be modified. The rule should state that pointers
>derived from the same object directly in the program must
>compare equal. Pointers obtained from the OS need not follow
>this rule, in that case it is implementation defined.
>This is the case for pointers way off the end of an array:
>it is implementation defined.

Remember that the ARM is a reference manual, not a standard.
I believe that the ANSI C standard makes it clear that for
programs that invoke code whose behaviour is "undefined", all
bets are off. (The usual remark is that the system is allowed
to spew frogs from the tape-drive, or something equally ridiculous,
so desires). This is equally true of programs that invoke the
operating system (other than by standard library functions
defined in the ANSI C standard). Any guarantees about the
behaviour of such programs must be made by a standard for that
particular operating system, not by the ANSI C standard.
The same will apply to the ANSI or ISO C++ standard, when
it arrives.

--
Fergus Henderson             [e-mail]
This .signature virus is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!