Home My Page Projects Modern C
Summary Activity Forums Tracker News SCM Files

Forum: discussion

Monitor Forum | Start New Thread Start New Thread
RE: Invalid pointers - takeaway 2.11.1.13 [ Reply ]
By: Jens Gustedt on 2020-06-07 07:56
[forum:153507]
Hi Jose Osorio,
these are many questions in one :-)

Be asured that this chapter is very carefully designed and formulated, so basically all the properties you find surprising are just that, surprising, but true in general nevertheless. But your questions show that you well understood the difficulties here, so at least I probably got the message accross :))

This does not mean that your platform will necessarily do nasty things when you just increment a pointer too far, most modern architectures wouldn't, but that there may be (and probably still are) architectures out there were this is problematic. And since much of the point of C is portability, you should not do this.

The reason for these restrictive rules are architectures with a segmented address space, where pointers not just hold "numbers" but are composed of two "numbers" a "segment pointer" and an "offset" into that segment. Depending on how such pointers then are represented (e.g loaded into two different hardware registers) a simple addition that goes too far out of bounds may constitute an arithmetic overflow for the offset value and result in a crash.

Similar observations hold for synthesing pointer values to dangling pointers, e.g by copying them. The action of initializing pointer values may trigger some complicated actions such as reading segment registers and alike, and so even that may already give you a fault. This rule is generally refered to as "pointer end-of-life zap" and has been much discussed recently, for C as well as for C++. There is now a strong movement to remove that rule from both languages, but, if ever, it will only appear in the standards in the mid-20th, I guess.

(For the unitialized local pointer: sure all automatic variables are uninitialized if you don't initialize them explicitly, pointers are no exception. Most of the time initialization can be completely optimized by modern compilers, so you should always do that and stay safe.)

Best
Jens

Invalid pointers - takeaway 2.11.1.13 [ Reply ]
By: Jose Osorio Azevedo Neto on 2020-06-06 23:07
[forum:153505]
Takeaway 2.11.1.13 on page 139 surprised me. It says: "A pointer must point to a valid object or one position beyond a valid object or be null". Two boxes illustrate the takeaway. The second box is clear that just incrementing a pointer to outside the object by more than one position may be enough to provoke a crash, even if no object is really accessed there. I have never seen this and I could not find anything in C17 about this.
Furthermore, on page 137 you show two examples, sum3 and sum4, where the pointer is left one position *before* the object and no crash is mentioned. It is possible to imagine algorithms where the pointer is changed by amounts greater than one, even in random ways, and sometimes the pointer is set to outside the object, but in those cases it is never dereferenced. I think those algorithms would be correct.
A related question is: when an object reaches the end of its lifetime, but a pointer to it remains alive, but it is not dereferenced, may a crash occur? Another question: is it possible to declare a local pointer without immediately initializing it?
I would expect a weaker takeway: "A pointer must not be dereferenced unless pointing to a valid object". What do you think?
Congratulations for your wonderful book,
Jose Osorio