3 ms·
So how does anything in this article add to my knowledge of c? I've been getting along just fine with the definition of pointers as agreed and employed by compi
by dave2000 11y ago
So how does anything in this article add to my knowledge of c? I've been getting along just fine with the definition of pointers as agreed and employed by compilers and developers for a long time. This article appears part wrong, part obvious and part pointless.
- netheril96 11y ago> This article appears part wrong, part obvious and part pointless. Nothing in this article is wrong. What adds to your knowledge of C is that certain operations on C pointers that would make sense if they were just bit pattern are actually undefined behavior. Undefined behavior may lead to subtle bugs due to how compilers do optimizations.
- dave2000 11y agoI don't see how comparing the value of a pointer, the area of memory to which it points having been previously freed, is undefined behaviour. Is there a source in the spec for this?
- belovedeagle 11y agoYes, it's in the article. > I don't see how [. . .] is undefined behaviour. This is a perfectly meaningless sentence. "Undefined behavior" doesn't mean "things which don't make sense in a particular implementation", it literally means behavior not defined by the spec. The spec declines to define the meaning of p==q when p and/or q is a freed pointer. There's nothing to "see" here: it's just not defined.
- TheCoelacanth 11y agoDid you miss the part where two pointers with identical bit patterns can compare not equal? E.g. in recent versions of gcc #include <stdio.h> int main(void) { int x, y; int *p = &x + 1; int *q = &y; printf("%p %p %d\n", p, q, p == q); return 0; } prints 0x7f7fffffdafc 0x7f7fffffdafc 0
- deleted 11y ago[deleted]
- botw 11y agoThis is interesting. If this is true, then a lot of code based on the assumption p == q would be broken.