News for hackers. Stuff that matters.
Re:C pointers are not hardware pointers by skissane on Monday March 07, 2016 @06:25AM (#11238294)
In general you are correct that C function arguments are passed by value. However, in the case of free() specifically, an implementation which treated the argument of free() as if it were passed by reference would be conforming. Obviously one cannot write a free() implementation in standard C with this behaviour, but there is no requirement that a conforming implementation's standard library functions such as free() have to be written in standard C (or indeed in C at all.)

As rm445 quoted C11 clause 6.2.4 para 2, "The value of a pointer becomes indeterminate when the object it points to (or just past) reaches the end of its lifetime". Hence, prior to free(p), p had a determinate value, now it has an indeterminate value. The standard imposes no requirement that it has the same value as it had before (indeed, such a requirement would contradict the explicit statement that the value is now indeterminate.) Any reliance on p having some particular value post free(p) is relying on undefined behaviour, and in undefined behaviour one is allowed to do anything at all, including giving free(p) pass-by-reference argument handling.

Re:C pointers are not hardware pointers by dllthomas on Tuesday March 08, 2016 @12:44AM (#11243736)
While I'm not sure there's no language preventing call-by-reference semantics around the pointer value, I agree that you could not distinguish without invoking undefined behavior, so it probably doesn't matter any.

Interestingly, the free() might poison not only the pointer passed in but all identical pointers as well.

This seems to allow us to implement pointers with two hops - the bits stored in a pointer value indexing into a lookup table that contains the actual address of the object. In that case, free could manipulate that table, invalidating existing pointers.