Basically you have no guarantee where the pointer q is pointing to.
Some compiler/static code analyzer will yell at you with this code.
Pointers Are More Abstract Than You Might Expect in C
11–20 of 267 posts
Re: Pointers Are More Abstract Than You Might Expect in C
#12Earlier quoted context omitted.
> the compiler needs to optimise ... wants to. There fixed that for you ;-) 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. Which is why the Linux kernel, among others, has to set…
What does "softening" the semantics mean? Aren't they pretty unambiguously defined by the standard?
Newer versions of the standard.
Re: Pointers Are More Abstract Than You Might Expect in C
#13This scratches the surface of why I hope C slowly fades away as the default low-level language. C sounds simple when you look through K&R C. C lets you feel like you understand the stack, ALU and memory. A pointer is just an integer and I can manipulate it like an integer. But the reality is filled with a staggering number of weird special cases that exist because memory doesn't work like a simple flat address space;…
The following is purely my opinion.
Rust might have gone too far the other way. Yes it strives to be a modern language, with a lot of functional programming features and "OOP" done right (aka no inheritance, simply method polymorphism). To me Rust is more a C++ replacement than a C replacement.
A replacement for C should try to be as simple as possible while fixing C weak typing mess with strong typing for instance, including when it comes to pointers (for instance like in Ada where you can't just take the address of anything you want, you need to declare it as aliased to begin with). In fact Ada tries hard to make pointers redundant which is a great thing. This and range types and bound check arrays( Ada has a lot lot of great ideas, and "C style" Ada is a treat to use).
So a C replacement should keep the procedural nature of C, with closures perhaps, but not go further in terms of paradigm. C aficionados often claim they love C because it's "simple"(it isn't) That's what they mean, they love C because you can't really do OO with it.
On the other hand, Rust macros are exemplary of what a good macro system should be.
Re: Pointers Are More Abstract Than You Might Expect in C
#14This scratches the surface of why I hope C slowly fades away as the default low-level language. C sounds simple when you look through K&R C. C lets you feel like you understand the stack, ALU and memory. A pointer is just an integer and I can manipulate it like an integer. But the reality is filled with a staggering number of weird special cases that exist because memory doesn't work like a simple flat address space;…
The following is purely my opinion. Rust might have gone too far the other way. Yes it strives to be a modern language, with a lot of functional programming features and "OOP" done right (aka no inheritance, simply method polymorphism). To me Rust is more a C++ replacement than a C replacement. A replacement for C should try to be as simple as possible while fixing C weak typing mess with strong typing for instance,…
I think it will only happen the way of Luddites in systems programming.
Even if redo Modula-2 with curly brackets I am not sure it would pick up.
Re: Pointers Are More Abstract Than You Might Expect in C
#15Basically you have no guarantee where the pointer q is pointing to. Some compiler/static code analyzer will yell at you with this code.
isn't it guaranteed that is points sizeof(int) bytes higher than the address of b?
Whether something useful is behind that address is another question
Re: Pointers Are More Abstract Than You Might Expect in C
#16This scratches the surface of why I hope C slowly fades away as the default low-level language. C sounds simple when you look through K&R C. C lets you feel like you understand the stack, ALU and memory. A pointer is just an integer and I can manipulate it like an integer. But the reality is filled with a staggering number of weird special cases that exist because memory doesn't work like a simple flat address space;…
On top of that C just got here thanks to widespread of UNIX and POSIX, and we had so much better options.
Yes they were languages with helmet, seat belts and airbag bolted on, but just like old technology cars on a motorway crash, the CVE database shows what happens when things go wrong.
Re: Pointers Are More Abstract Than You Might Expect in C
#17the comparison at the start is nonsense - there is no specification for the ordering or location of stack variables. by taking the address of these variables, you could see that they actually are the same value, and so intuitively you’d think they might be the same, but a different compiler might put them in different locations. or they may be elided entirely through optimisation. it’s far safer to fail the equality test in this case - this is what the model specifies.
this is not even the first example of this counter-initiative behaviour. imagine two floating point values with exactly the same bit-representation. it is possible, without any trickery for them to fail an equality check - i.e, they are both NaN.
this is what IEE754 demands of a compliant floating point implementation. and indeed, it’s a sane choice when you understand why it was made.
similarly, it’s perfectly reasonable for this example to fail.
Re: Pointers Are More Abstract Than You Might Expect in C
#18Basically you have no guarantee where the pointer q is pointing to. Some compiler/static code analyzer will yell at you with this code.
isn't it guaranteed that is points sizeof(int) bytes higher than the address of b? Whether something useful is behind that address is another question
From reading the spec it seems that is undefined behaviour for anything other than `&b + 1`. That is one past the end of b is fine but not `&b + 2` etc.
Re: Pointers Are More Abstract Than You Might Expect in C
#19Just a datapoint: VS2017 on Win10 x64 gives me 00AFF89C 00AFF894 0, which is what I naively expect.
Actually, you should not expect that, because you don't have a guarantee of ordering of the addresses of a and b on the stack.
Now try with /O2 . (-:
Re: Pointers Are More Abstract Than You Might Expect in C
#20I like the behavior of the compiler here. There is no guarantee that a and b are next to each other in memory. That's why the comparison fails, the alternative makes is runtime/compiler/optimization level dependent which would be a total mess.
As usual with those C bashing articles you won't run into trouble if you don't try very hard to write contrived code. I mean, the moment you see:
int *q = &b + 1;