9 ms·
I think you're right. I also take issue with the "pointers point at an object, one byte into it or are null" statement. A pointer is a piece of memory/registe
by dave2000 11y ago
I think you're right. I also take issue with the "pointers point at an object, one byte into it or are null" statement. A pointer is a piece of memory/register that contains an address, and an address is just a bit pattern. 0 is an address, as is 1,2,3.... 0xffd9303e. It doesn't even have to be accessible memory; you can get all sorts of exciting effects if you write to or even read from addresses mapped to hardware but the datatype is still a pointer.
- dllthomas 11y agoMy vague recollection of the relevant bits of the C standard has it that there are a few differences between how pointers to void, pointers to char, and pointers to anything else are treated in some respects. This might be one of them. "A pointer is a piece of memory/register that contains an address, and an address is just a bit pattern." This is true on virtually every modern system, but (if memory serves) not literally every system ever, and the C standard leaves room for some surprising things in some places. It would have been very nice if the author had actually included some references, though.
- jibsen 11y agoPointers to character types get some special treatment. They can be used to address the individual bytes of other objects (C11 6.3.2.3p7), and the strict aliasing rule allows character types to be used to access those bytes (6.5p7) (one interesting note is that uint8_t is not strictly required to be a character type [1]). The problem with assuming things like a pointer working like an integer, is that compiler vendors may choose to start taking advantage of any undefined behavior and point to the standard if you complain. [1]: https://gist.github.com/jibsen/da6be27cde4d526ee564 https://gist.github.com/jibsen/da6be27cde4d526ee564
- belovedeagle 11y agoSeems like you missed the whole point of the article, which was that an abstract "pointer" is not the same thing as the bit field held in some register or memory location, any more than a Java Object is.
- dave2000 11y agoSo 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