From 3580589436118511743 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,e94695845965b249 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1992-12-19 15:59:34 PST Newsgroups: comp.std.c++ Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) Subject: Re: Zero-length structures and pointer comparisons Message-ID: <1992Dec20.012551.11306@ucc.su.OZ.AU> Sender: news@ucc.su.OZ.AU Nntp-Posting-Host: extro.ucc.su.oz.au Organization: MAXTAL P/L C/- University Computing Centre, Sydney References: <1992Dec8.173855.18153@meaddata.com> <1992Dec10.121935.19315@ucc.su.OZ.AU> Date: Sun, 20 Dec 1992 01:25:51 GMT Lines: 76 In article kanze@us-es.sel.de (James Kanze) writes: >In article <1992Dec10.121935.19315@ucc.su.OZ.AU> >maxtal@extro.ucc.su.OZ.AU (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, maxtal@extro.ucc.su.oz.au Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------