Hacker News Reader

Comment by userbinator | Hacker News Reader

If we initialize the contents of both pointers to 0

Is this a "Rust-ism"? I had a double-take while reading that, because in C that would mean a null pointer, and in the terminology I'm used to, the intent is to set the pointee to 0.

Note that x86 does allow some memory reordering:

https://preshing.com/20120515/memory-reordering-caught-in-th...

(I have experience debugging and fixing an extremely rare bug caused by the above subtle reordering, which occurred approximately once every 3-4 months.)

View on HN

> Is this a "Rust-ism"?

It doesn’t ring a bell to me as someone who’s spent a lot of time in the Rust community, so I’d say it’s probably just a difference in personal jargon rather than a Rust versus C thing.

(Rust usually uses “reference” instead of “pointer” anyway.)

References and (raw) pointers are distinct things with very different semantics. (References are borrow checked.)

Also, references are not guaranteed to be indirections in machine code (which is the definition of a pointer).

Yes, they are – well, as much as raw pointers are. In reality, the optimizer can always remove indirections when it can prove that doing so doesn’t affect visible semantics, but that applies equally to raw pointers and references.

(edit: replaced asterisks with “[asterisk]” since HN’s Markdown has no way to escape them.)

Critically, Rust references have pointer identity: you can convert between references and raw pointers, and if you convert a [asterisk]const u32 to &u32 and back to [asterisk]const u32, the pointers are guaranteed to compare equal. In my opinion this is unfortunate. It would be nice if the compiler could represent &u32 in memory as if it were just u32, i.e. just pass the value rather than a pointer. After all, the pointed-to value is guaranteed to remain unchanged as long as the &u32 exists. And passing by value is almost always faster for small values (where the size of a value <= the size of a pointer); the programmer could just pass by value directly, but only if they know it’s a small value, which isn’t the case in generic code. Unfortunately, the ability to compare pointer identities means that you really do need a pointer, even though most code never does so. (LLVM can transform pointers to values for local variables and even function arguments if it can prove that the actual code never checks pointer identity, but again, that applies to both references and raw pointers; most of the distinction between the two has been lost by the LLVM IR stage anyway.)

C programmers use "contents" to refer to the address of the pointer? As a non-C programmer, asking what is "contained" in the pointer would certainly refer to the pointee.

C and Asm at least... and "address of the pointer" is something entirely different. For example (assuming a 16-bit system and radix 16 for brevity),

    Name:    Address:    Value:
    p        0100        02 01
    v        0102        12 59

p is the pointer. The address of p is 0100. The contents of p are the two bytes which form the address of v, 0102. The contents of v are the two bytes which form the value 5912.

I wonder if this confusion of the pointee with the pointer is what makes this concept seem so difficult to those who didn't start with Asm (especially multiple indirections) --- I certainly saw a lot of that when I used to teach CS courses.

> I wonder if this confusion of the pointee with the pointer is what makes this concept seem so difficult to those who didn't start with Asm

Possibly (I started with asm, so I can't speak with certainty) but it could also be because many modern programmers first learned Java or JavaScript or Python in which most names are references to object (thus effectively all variables are addresses). Their first languages do not have value semantics, so grasping the concept of value semantics applied to a reference itself (ie pointers) is a major stretch.

JavaScript does have value semantics for booleans and numbers. But it doesn't have any reference types which allow you to inspect the reference as a value.

In Python, everything is a pointer to a PyObject and always passed by value, so thinking of them as values makes sense. You can even easily get the address of the pointer by calling id on it (but not as easily convert it back).

doesn't id return the address of the pointee?

Ah, yes - the value of the pointer, which is an address, the address of the pointee. (Even after reading that other thread, I messed up my terminology.)

Actually, id returns a pointer to a PyObject representing an integer, the value of which is the value of the pointer that was passed as an argument, which is the address of the pointee. Right?

In C a pointer is an object in its own right, so referring to the contents of a pointer, p, means the same thing as referring to the contents of an integer, i; namely, the value held by the object. A pointer value has semantic meaning and usefulness the same as an integer value, completely divorced from the machine representation, which in a pure C program should always be irrelevant for pointer and arithmetic types alike.

I don't think I can articulate well why it's important to keep in mind and appreciate value semantics. Certainly many C programmers, especially the newer ones, are far too concerned with value representation rather than the abstract value itself, often conflating the two. I guess one good example of why it's important to understand pointers as proper objects with abstract values is when working with pointers-to-pointers, pointers-to-pointers-to-pointers, etc. Pointer arithmetic is another case, which doesn't overlap with the former as much as you'd think. In these cases understanding pointers as values is important to understanding the semantics of a program, and more generally how to leverage the language efficiently and safely. Note that these semantics have no analog in references, the construct in, e.g., C++. It doesn't make sense to conceptualize references as independent objects; rather, a reference is a syntactic construct, no more an object than a list initializer.

Yeah, as a C programmer I would find it kind of odd if someone seemed to conceptually elide the character of pointers as proper first-class objects.

I wonder if pointer arithmetic specifically is the sticking point here; when using pointers in other languages I don't ever do pointer arithmetic on them, so the integral value of the pointer is easily ignored.

For those wondering, given the context of Rust here, both references and C-style pointers are first-class in Rust, but references (which are overwhelmingly more common) don't directly permit pointer arithmetic at all, and would require one to first cast the pointer to an integer.

A pointer does not contain what it points to, it just points to it.

The content (the value) of a pointer is an address.

> which occurred approximately once every 3-4 months

ouch that hurts. You should be proud of that fix....I guess you kinda are :D

I've never thought about that aspect of the my writing, but I use the terms "value of the pointer" to mean the address, and "contents of the pointer" to mean whats stored at the address.

Yes, "targets" would be clearer than "contents" here.

> in C that would mean a null pointer

It's a Rust-ism. In Rust there is no null.

Raw pointers in Rust can be null.

(star)const T and (star)mut T both have an is_null method and there is std::ptr::null and std::ptr::null_mut available to create null pointers.

Reply on news.ycombinator.com