"Paul D. DeRocco" <pderocco@ix.netcom.crud.com> writes:

|>  Tom Payne wrote:
|>  >
|>  > It is my understanding from earlier postings in this and related
|>  > groups that, per the C and C++ standards, accessing a pointer that
|>  > points to an invalid object in any way other than assigning it a new
|>  > value generates undefined behavior.  I consider this design decsion a
|>  > bit surprising, even unfortunate, but, as I recall, it was made as a
|>  > concession to the 386 architecture, which has bad-pointer traps
|>  > associated with certain registers.
|>
|>  What does it have to do with the 386? All modern CPUs will trap on some bad
|>  pointers, or just clobber user memory on others.

Only if you access through the pointer.  The problem Tom Payne is
referring to is the undefined behavior that results in even just
accessing the pointer.

And I don't think that the 386 was the only motivation.  The fastest way
to copy and/or compare pointers on a 386 does not involve loading the
segment registers (although a naive implementation might do so for
copy).  On the other hand, I know of at least one processor (from
Honeywell-Bull) with 20 bit address registers and 16 bit general
registers.  I don't know if just loading an address register would cause
a trap on this processor, but it is conceivable.

|>  By the way, one other thing you routinely do to pointers to invalid objects,
|>  without problems, is comparing them, either to NULL or to another pointer.
|>  One-past-the-end pointers are a common example.

With regards to validity, in C and C++, there are three types of
pointers:

1. Pointers to a valid object.  All normal operations are valid.

2. Null pointers, or pointers to one past the end of an array.  (In this
regard, I think that a scalar is the equivalent of an array with one
element.)  Any attempt to dereference the pointer is undefined behavior,
but you can still copy and compare them; in the case of a pointer to one
past the end of an array, pointer arithmetic is still valid (but not
adding a positive number).

3. Invalid pointers: any attempt to access the pointer (and not just
what it points to) is undefined behavior.  If such a pointer is the
result of pointer arithmetic, it is also undefined behavior.

Thus:

    int a[ 10 ] ;
    int* p = a + 11 ;             //  undefined behavior

    int* p = (int*)malloc( sizeof( int ) ) ;
    free( p ) ;
    if ( p == NULL )              //  undefined behavior

BTW: if someone could quote the exact passage in the C standard or the
C++ draft which specifies this.  I've seen the issue discussed often
enough on comp.std.c and comp.std.c++ to be sure that my statements
above are correct, but I am unable to find an explicit rule.  The
closest I can come (from the C standard) is: (6.1.2.4) "The value of a
pointer that referred to an object with autormatic storage duration that
is no longer guaranteed to be reserved is indeterminate.", (7.10.3) "The
value of a pointer that refers to freed space is indeterminate", and
(6.3) "If an exception occurs during the evaluation of an expression
(that is, if the result is not mathematically defined or not in the
range of representable values for its type), the behavior is undefined."
Presumably, the argument is that a value which is "indeterminate" is "not
mathematically defined."  (Presumably, also, the C++ draft has similar
wording somewhere.  I guess it says something about the relative
complexity of the languages that I find it easier to search a paper copy
of the C standard than my on-line copy of the C++ draft, grep et
al. notwithstanding.)

Finally, I'm cross-posting this to comp.std.c++ and comp.std.c, and
setting followups there.  Because it is cross-posted to both a C and a
C++ group, please pay attention in your answers, and specify which
language you are talking about.  (And if you are only responding
concerning one language, don't be afraid to restrict your follow-up to
the appropriate group; there are a lot of people in comp.std.c, in
particular, who really don't care what C++ does.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
        I'm looking for a job -- Je recherche du travail
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]