Undefined behavior is often a thing for C programmers (2011)

Re:Undefined behavior is often a thing for C programmers (2011) by sharpneli on Thursday September 03, 2020 @12:02PM (#24365402)

The reasons for that are performance. So that one doesn't have to assume everything aliases everything else. It could be more clear though, like having explicit alias qualifier which would make it alias all and by default nothing aliases, or vice versa. Right now there is no easy way to make two unrelated types alias, one has to go via char* or use unions.

You can cast void* to something else and it will work, but you can't expect to get a random void* and presume it has some valid well defined data for you to read. You must know where it came from and what's been done to it.

As a rule of thumb if you just write dumb bytes it's char*. If it's anything else you must know what you're doing and there are ways to perform type punning that's within the spec.

[ Parent | on HN ]

Re:Undefined behavior is often a thing for C programmers (2011) by abainbridge on Thursday September 03, 2020 @12:10PM (#24365500)

> The reasons for that are performance. So that one doesn't have to assume everything aliases everything else.

Can you expand on that? I don't understand.

Edit: I see the answer in one of your other comments:

> If len and array are both of the same type then the compiler must assume they can alias (or one of them is char*). One has to explicitly state with restrict that they cannot alias.

I'd happily take that hit. I can put restrict in the hot paths of my code. I'm tempted to say I want restrict to be the default, but I haven't thought that through.

[ Parent | on HN ]