jimad@microsoft.UUCP (Jim ADCOCK) (07/31/90)
Proposed: 1) That null references explicitly be defined as legal in the language. A null reference is that which is created from a "dereferenced" null pointer such as follows: FOO& fooref = *((FOO*)0); 2) That "dereferencing" null pointers except in the initialization of references be explicitly defined as not legal in the language. The exact effect of dereferencing a null pointer would be "implementation defined", but the intent is that no legal object can be referenced via a null pointer. [disclaimer: this posting represents the opinions of an individual C++ user]
rls@onondaga.steinmetz.ge.com (Rod Sprattling) (08/01/90)
One use for dereferencing null pointers leaps to mind. Consider this
definition, used in Intrinsics-based widgets in the X Window System:
Copyright 1987, 1988 by Digital Equipment Corporation, Maynard,
Massachusetts, and the Massachusetts Institute of Technology,
Cambridge, Massachusetts. All Rights Reserved.
#define XtOffset(type,field) \
((unsigned int) (((char *) (&(((type)NULL)->field))) - \
((char *) NULL)))
It's used to calculate offsets into the elements of a struct, as
in this snippet from a fictional wristWatch widget:
static XtResource Resources[] =
{
{ XtNwatchFaceColor,
XtCFaceColor,
XtRString,
sizeof(char *),
XtOffset(GIWristWatchWidget, watch.face_color),
XtRImmediate,
"White"
},
....
Can anyone else think of a situation where null dereferencing is
useful, besides compile-time calculation of offsets?
Rod
--
---------------------------------------------------------------------
__ __
|__)(__' Don't worry about not seeing the top....
| \___) _ o
-_ -\>
-_<\
-_
-_
...so much as seeing the bottom.
Roderick Sprattling DialCom: 8*833-7054
sprattlingrl@crd.ge.com rls@onondaga.crd.ge.com
uunet!crd.ge.com!sprattlingrl
---------------------------------------------------------------------rfg@NCD.COM (Ron Guilmette) (08/01/90)
In article <56159@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: >Proposed: > >1) That null references explicitly be defined as legal in the language. A >null reference is that which is created from a "dereferenced" null pointer >such as follows: > > FOO& fooref = *((FOO*)0); > >2) That "dereferencing" null pointers except in the initialization of references >be explicitly defined as not legal in the language. The exact effect >of dereferencing a null pointer would be "implementation defined", but the >intent is that no legal object can be referenced via a null pointer. > >[disclaimer: this posting represents the opinions of an individual C++ user] Jim, It appears that you are going to be making a lot of proposals. That's fine, but if you want them taken seriously, you should try to come up with some very specific wording that could be incorporated directly into the ANSI draft document. Also, you should try to specify what section of E&S we are talking about for this proposal and you should say where and how your new proposed text should be fitted together with the existing wording in that section. For instance: 8.4.3 References Strike the first sentence and replace it with: "A variable declared to be a T&, that is `reference to type T' (&8.2.2), must be initialized by a value of type T&. For the initializer of a reference, a conversion of a type T value to a type T& value will be implicitly supplied by the compiler where needed." "If the initializer for a reference is an expression whose last operation is the dereferencing of a pointer valued subexpression via the unary `*' operator, then the evaluation of the initializer expression will not include the application of the final unary `*'. Rather, in such cases, the reference will be initialized to refer to the same portion of memory as does the pointer-valued sub- expression. (Note that the value of the pointer-valued subexpression may legally be NULL.)" "Similarly, if the initializer for a reference is an expression which (before implicit conversions are applied) itself has the same reference type, then the evaluation of the initializer expression will not include the application of normal implicit conversion of that reference type value to its corresponding (referent) object type value. Rather, the reference value itself will initialize the reference object which is being initialized." -- // Ron Guilmette // C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
henry@zoo.toronto.edu (Henry Spencer) (08/02/90)
In article <RLS.90Jul31125458@onondaga.steinmetz.ge.com> rls@onondaga.steinmetz.ge.com (Rod Sprattling) writes: > >One use for dereferencing null pointers leaps to mind. Consider this >definition, used in Intrinsics-based widgets in the X Window System: > >#define XtOffset(type,field) \ ... The correct way to deal with this is with ANSI C's `offsetof' macro, which can do whatever magic is necessary in a particular implementation. That is, there is no need to invent a solution -- e.g. allowing null dereferencing -- for this problem, it has already been solved. -- The 486 is to a modern CPU as a Jules | Henry Spencer at U of Toronto Zoology Verne reprint is to a modern SF novel. | henry@zoo.toronto.edu utzoo!henry
jimad@microsoft.UUCP (Jim ADCOCK) (08/17/90)
In article <1028@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: >Jim, > >It appears that you are going to be making a lot of proposals. That's fine, >but if you want them taken seriously, you should try to come up with >some very specific wording that could be incorporated directly into the >ANSI draft document. Also, you should try to specify what section of E&S >we are talking about for this proposal and you should say where and how >your new proposed text should be fitted together with the existing wording >in that section. I'm not sure I buy this. I'd like to have comp.std.c++ be the forum for "public input" on the c++ standard. This is the spirit in which I am writing to comp.std.c++ Hopefully, at least on some issues, public input will reach some kind of general consensus on how some of the loose ends in C++ should be resolved. But, eventually what's going to happen is a representatives from various compiler vendors, etc, are going to have to sit down in a room, hammer out the exact details, and fix the wording in the C++ documentation. That is the place where things are going to have to get really formal, not in public discussion. However, the wording can't get fixed until the intent is nailed down. In any case, I hope to be able to restrain myself from making lots of proposals. I'm mainly trying to point out little loose ends that need to be cleaned up -- not major overhauls.