3 ms·

I'm surprised any seasoned C developer would make this mistake. You haven't been able to assume trivial translation of C code to assembly for decades. Casting

by nly 7y ago

I'm surprised any seasoned C developer would make this mistake. You haven't been able to assume trivial translation of C code to assembly for decades. Casting from a 'pointer to type A' to a 'pointer to type B' is unsafe in all but a handful of circumstances. - B is char or unsigned char. - A is char or unsigned char, and the pointer was previously cast from a pointer to type B. - Where A is a struct (or a standard layout[0] class in C++) and B is the first member of that structure. [0] https://en.cppreference.com/w/cpp/language/data_members#Standard_layout https://en.cppreference.com/w/cpp/language/data_members#Stan...

deleted 7y ago
[deleted]
catblast 7y ago
> I'm surprised any seasoned C developer I'm not too surprised. There is seasoned as in recently experienced (and burned).. and seasoned as outdated. I have come across plenty that don't realize the last 25 years of compiler optimizations have changed the rules of what can be assumed.
saagarjha 7y ago
> I'm surprised any seasoned C developer would make this mistake. Not everyone gets the talk. And even for the ones that do, many consider it to be useless nitpicking until it bites them. (And some who are bitten would prefer to yell at the compiler for “breaking their code”…) > A is char or unsigned char, and the pointer was previously cast from a pointer to type B. And if A is void, of course.
- gpderetta 7y ago
  > And if A is void, of course To nitpick, casting is rarely the issue. Dereferencing a pointer to the wrong type is the issue. As void can't never be dereferenced nor can be a valid underlying type, void never factors in alias analysis.
userbinator 7y ago
You haven't been able to assume trivial translation of C code to assembly for decades. Then perhaps everyone should continue to do that, and continue to very strongly complain to the compiler-authors who seem to have become absolutely engrossed in blindly following the standard to the letter and completely ignoring the fact that people are wanting C precisely because it's supposed to be close to Asm. But I guess it satiates their egos more to point and laugh... "we're following the standard, fuck you for thinking we care about anything else."
- nly 7y ago
  If the standard didn't allow this optimization then GCC would have to emit unaligned access instructions everywhere. If it did that then people who want C to be 'close to the machine' would be complaining about lackluster performance and calling for everything to be written in ASM. The reality is that the abstract machine modeled by C is a long, long way from what modern CPUs actually do, and the C language standards committee seems to have little interest in extending their language
  - userbinator 7y ago
    If you were compiling for an architecture that doesn't allow unaligned access, then you'd expect unaligned accesses to fault. If you were compiling for an architecture which does, then you'd wouldn't. That's what sane undefined behaviour should be expected to do.
  - asveikau 7y ago
    > The reality is that the abstract machine modeled by C is a long, long way from what modern CPUs actually do, But some modern CPUs fault on unaligned access or make such access slower. (I think Intel is actually sometimes in the latter camp.) I don't get why people label "modern" as a synonym for their pre-existing favorite idea and then demand stuff reflect that "modernity" or else it is totally illegitimate. Seems like some kind of hangup. As some have mentioned in similar discussions, even the x86 machine code does not reflect how the CPU really works, there are things like caching and branch prediction and speculative execution and microcode and ... There is a long list and probably no one person is aware of all the abstractions.
quietbritishjim 7y ago
Since we're being pedantic: I seem to remember that A or B can be char or unsigned char or signed char. Plain char can be signed or unsigned, but it is a distinct type from the other two regardless of that.
- saagarjha 7y ago
  I believe signed char is not legal in this case, precisely for the reason you specified.
  - quietbritishjim 7y ago
    Sorry, I just checked (I should've done that first!) and you are right. I had misremembered.

by nly 7y ago

deleted 7y ago

[deleted]

catblast 7y ago

> I'm surprised any seasoned C developer I'm not too surprised. There is seasoned as in recently experienced (and burned).. and seasoned as outdated. I have come across plenty that don't realize the last 25 years of compiler optimizations have changed the rules of what can be assumed.

saagarjha 7y ago

> I'm surprised any seasoned C developer would make this mistake. Not everyone gets the talk. And even for the ones that do, many consider it to be useless nitpicking until it bites them. (And some who are bitten would prefer to yell at the compiler for “breaking their code”…) > A is char or unsigned char, and the pointer was previously cast from a pointer to type B. And if A is void, of course.

gpderetta 7y ago
> And if A is void, of course To nitpick, casting is rarely the issue. Dereferencing a pointer to the wrong type is the issue. As void can't never be dereferenced nor can be a valid underlying type, void never factors in alias analysis.

userbinator 7y ago

You haven't been able to assume trivial translation of C code to assembly for decades. Then perhaps everyone should continue to do that, and continue to very strongly complain to the compiler-authors who seem to have become absolutely engrossed in blindly following the standard to the letter and completely ignoring the fact that people are wanting C precisely because it's supposed to be close to Asm. But I guess it satiates their egos more to point and laugh... "we're following the standard, fuck you for thinking we care about anything else."

nly 7y ago
If the standard didn't allow this optimization then GCC would have to emit unaligned access instructions everywhere. If it did that then people who want C to be 'close to the machine' would be complaining about lackluster performance and calling for everything to be written in ASM. The reality is that the abstract machine modeled by C is a long, long way from what modern CPUs actually do, and the C language standards committee seems to have little interest in extending their language
- userbinator 7y ago
  If you were compiling for an architecture that doesn't allow unaligned access, then you'd expect unaligned accesses to fault. If you were compiling for an architecture which does, then you'd wouldn't. That's what sane undefined behaviour should be expected to do.
- asveikau 7y ago
  > The reality is that the abstract machine modeled by C is a long, long way from what modern CPUs actually do, But some modern CPUs fault on unaligned access or make such access slower. (I think Intel is actually sometimes in the latter camp.) I don't get why people label "modern" as a synonym for their pre-existing favorite idea and then demand stuff reflect that "modernity" or else it is totally illegitimate. Seems like some kind of hangup. As some have mentioned in similar discussions, even the x86 machine code does not reflect how the CPU really works, there are things like caching and branch prediction and speculative execution and microcode and ... There is a long list and probably no one person is aware of all the abstractions.

quietbritishjim 7y ago

Since we're being pedantic: I seem to remember that A or B can be char or unsigned char or signed char. Plain char can be signed or unsigned, but it is a distinct type from the other two regardless of that.

saagarjha 7y ago
I believe signed char is not legal in this case, precisely for the reason you specified.
- quietbritishjim 7y ago
  Sorry, I just checked (I should've done that first!) and you are right. I had misremembered.