Earlier quoted context omitted.
Ahem! "which is what I naively expect."
My expectation was that they wouldn't be equal.
I already knew. (-: Tell mpweiher.
Pointers Are More Abstract Than You Might Expect in C
261–267 of 267 posts
Re: Pointers Are More Abstract Than You Might Expect in C
#262Note that if the two pointers are passed to a function, and the comparison is done in the function, the results are different: #include void pcmp(int *p, int *q) { printf("%p %p %d\n", (void *)p, (void *)q, p == q); } int main(void) { int a, b; int *p = &a; int *q = &b + 1; printf("%p %p %d\n", (void *)p, (void *)q, p == q); pcmp(p, q); return 0; } That is giving me: 0x7ffebac1483c 0x7ffebac1483c 0 0x7ffebac1483c 0x7…
Yup, what is described in the article looks like a bugged optimization to me were the runtime behavior differs from the static model used for the optimization. I am sure the actual runtime semantics is in fact to compare addresses but the optimization claims to know (falsely) enough about the pointers to determine they must be not equal.
I don't understand the people in this comment section defending this. The cited spec gives no evidence that this should happen (I fail to see the undefined behavior here). It specifies when pointers are equal, and both pointers ended up pointing to the same object, so they should be equal. Just because the compiler doesn't know, shouldn't mean it can replace an equality check with false.
The spec didn't say "also, they are not equal in case the conpiler thinks that they proooobably aren't pointing to the same object".
I do agree that one should avoid this type of pointer arithmetic, but that doesn't excuse the confusing behavior of this primitive operstion.
One should at least argue for the behavior to be consistent.
Re: Pointers Are More Abstract Than You Might Expect in C
#263Earlier quoted context omitted.
> To me Rust is more a C++ replacement than a C replacement Precisely. Rust is what C++ would be if it didn't need to be backwards compatible (though I'm not a fan of some of the syntax choices in Rust). Unfortunately, there's a reason C++ needs to retain backwards compatibility and its for that reason that Rust isn't going to replace C++ anytime soon. > That's what they mean, they love C because you can't really do…
The good thing about no-runtime languages is that you can mix modules written in them, within reason. So Rust can make inroads into existing C++ code bases where it makes sense faster than we think, without replacing C++ wholesale for a long time. Firefox itsef is likely such a codebase.
That's harder than you would think due to name mangling.
Basically they can only talk to each other through a C interface.
Re: Pointers Are More Abstract Than You Might Expect in C
#264Earlier quoted context omitted.
COM and WinRT are still based on the C ABI though. So anything that can do that, can do them - hopefully with more layers on top for convenience sake, of course...
Not quite, COM yes, although it is masochistic to do so without any higher level help. UWP on the other hand extends COM to support inheritance and value types across calls, and the lowest Microsoft was willing to go on their high performance components was the Windows Runtime C++ Template Library, now replaced by C++/WinRT bindings and updated MIDL compiler.
The ABI is still C. Value types are just structs, and inheritance is implemented via aggregation - under the hood, it's all just interfaces and conventions on how they all play together. So any language that can do C FFI, can do WinRT. We did most of it with Python and ctypes as a prototype.
And you could even use that from C back in the day if you #included the "Windows.*.h" headers that shipped with the SDK - they had a bunch of #ifdef __cplusplus etc in them. Not sure if that stuff is still there or not.
Re: Pointers Are More Abstract Than You Might Expect in C
#265Earlier quoted context omitted.
> The weird special cases were largely(1) introduced recently by optimizer writers hijacking the standard in order to soften the semantics so that previously illegal optimizations would now be legal, by simply declaring the vast majority of existing C code as "undefined" and up for grabs. Citation needed. Signed overflow being undefined behavior was a direct consequence of different hardware representations of number…
> I keep seeing people like you claim we should just "fix" undefined behavior Nope. Just don't take undefined behavior to mean "do arbitrary optimizations that dramatically alter the behavior of programs". Let's see what C89 says about undefined behavior: "3.4.3 Undefined behavior --- behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately-valued objects, for which…
Your post basically boils down to "don't do any optimizations that might possibly exploit undefined behavior". That covers most optimizations. That means compilers can only use -O1. Proving you can still optimize is often equivalent to the halting problem (or you emit lots of branches and duplicate implementations for each function so the code can test the parameters and take the "safe" path in some cases or the "fast" path in others).
> silently do arbitrary optimizations
What are arbitrary optimizations to you? This isn't the magical land of unicorns here. Compilers have to be pedantic by nature so you have to sit down and come up with what is allowed and isn't allowed.
I happen to agree that some instances of undefined behavior should be defined and eliminated. For example, uninitialized values. Require the compiler to zero-initialize any storage location before use unless it can prove an unconditional write occurs to that location. This will have a small but manageable code size impact and a relatively small runtime perf impact.
> removing arbitrary code
The compiler is just a series of meaningless instructions executing on meaningless data on a dumb machine. It has absolutely no way to understand what is "arbitrary" code and what isn't. This is basically another argument for "compilers should disable 95% of all optimizations".
Re: Pointers Are More Abstract Than You Might Expect in C
#266Note that if the two pointers are passed to a function, and the comparison is done in the function, the results are different: #include void pcmp(int *p, int *q) { printf("%p %p %d\n", (void *)p, (void *)q, p == q); } int main(void) { int a, b; int *p = &a; int *q = &b + 1; printf("%p %p %d\n", (void *)p, (void *)q, p == q); pcmp(p, q); return 0; } That is giving me: 0x7ffebac1483c 0x7ffebac1483c 0 0x7ffebac1483c 0x7…
You're right, unless pcmp is declared as static (then the compiler inline the function)
#include
#include
static void pcmp(void *p, void *q)
{
printf("%p %p %d %d(sub) %d(cast)\n", p, q, p == q, !(p - q),
(uintptr_t)p == (uintptr_t)q);
}
int main(void)
{
int a, b;
void *p = &a;
void *q = &b + 1;
printf("%p %p %d %d(sub) %d(cast)\n", p, q, p == q, !(p - q),
(uintptr_t)p == (uintptr_t)q);
pcmp(p, q);
return 0;
}
$ gcc -std=gnu11 -O1 pq.c
$ ./a.out
0x7fffde6612ec 0x7fffde6612ec 0 1(sub) 1(cast)
0x7fffde6612ec 0x7fffde6612ec 0 1(sub) 1(cast)
Re: Pointers Are More Abstract Than You Might Expect in C
#267Earlier quoted context omitted.
> The weird special cases were largely(1) introduced recently by optimizer writers hijacking the standard in order to soften the semantics so that previously illegal optimizations would now be legal, by simply declaring the vast majority of existing C code as "undefined" and up for grabs. Citation needed. Signed overflow being undefined behavior was a direct consequence of different hardware representations of number…
> I keep seeing people like you claim we should just "fix" undefined behavior Nope. Just don't take undefined behavior to mean "do arbitrary optimizations that dramatically alter the behavior of programs". Let's see what C89 says about undefined behavior: "3.4.3 Undefined behavior --- behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately-valued objects, for which…
Firstly, "ignoring the situation completely with unpredictable results" is a pretty clear permission to do arbitrary optimizations, as long as they preserve the semantics in the case where the execution doesn't exhibit UB.
Secondly, in ISO standards Notes are by definition non-normative, hence your exegesis as it pertains to C99 and later versions is invalid anyway.