4 ms·

For certain types of image manipulations or other computations, it may well be that the pointers are supposed to refer to overlapping regions. This is the kind

For certain types of image manipulations or other computations, it may well be that the pointers are supposed to refer to overlapping regions. This is the kind of problem that, as Dennis Ritchie pointed out, bedeviled FORTRAN for ever. I think the solution is to fix "restricted" and let programmers opt-in. If the programmer doesn't do that, or gets it wrong, too bad.

comex 8y ago
The issue isn’t just that src->data and dest->data might overlap, which TBAA doesn’t forbid anyway (although that’s what restrict can help with). It’s that dest->data might alias src->len, and magically change the length midloop. I doubt there’s any legitimate image manipulation where that would happen, but the compiler doesn’t know that...
- vyodaiken 8y ago
  This is exactly why I don't propose to do away with UB but to limit what compilers can do with UB. The programmer in C cannot be prevented from writing terrible code where e.g. a loop counter is written over by an aliased pointer in the middle of the loop - the current standard doesn't prevent it either. In fact, strictly conforming C code can use char pointers to randomly write over any aliased variables if I understand it correctly. The positive thing about UB is that it makes this the programmers problem, not the compilers problem. The negative thing is that in current interpretations, the compiler is free to detect such an error and then instead of either failing to compile with a warning or just letting things happen as the programmer has specified, it can introduce global program failures because "it's impossible to have UB".
geofft 8y ago
Your proposals are going to slow down tons of real-world C programs that are not engaged in these types of manipulations, to the point where people writing high-performance software are better off using Python, or need to make so many changes to their source code to recover reasonable performance that they might as wll make a few more changes and end up with Go and Rust. If you really think C is enough of a disaster that this is justified, why even care about fixing C?
- vyodaiken 8y ago
  If you could actually provide some concrete basis for that argument, it would be interesting.

comex 8y ago

The issue isn’t just that src->data and dest->data might overlap, which TBAA doesn’t forbid anyway (although that’s what restrict can help with). It’s that dest->data might alias src->len, and magically change the length midloop. I doubt there’s any legitimate image manipulation where that would happen, but the compiler doesn’t know that...

vyodaiken 8y ago
This is exactly why I don't propose to do away with UB but to limit what compilers can do with UB. The programmer in C cannot be prevented from writing terrible code where e.g. a loop counter is written over by an aliased pointer in the middle of the loop - the current standard doesn't prevent it either. In fact, strictly conforming C code can use char pointers to randomly write over any aliased variables if I understand it correctly. The positive thing about UB is that it makes this the programmers problem, not the compilers problem. The negative thing is that in current interpretations, the compiler is free to detect such an error and then instead of either failing to compile with a warning or just letting things happen as the programmer has specified, it can introduce global program failures because "it's impossible to have UB".

geofft 8y ago

Your proposals are going to slow down tons of real-world C programs that are not engaged in these types of manipulations, to the point where people writing high-performance software are better off using Python, or need to make so many changes to their source code to recover reasonable performance that they might as wll make a few more changes and end up with Go and Rust. If you really think C is enough of a disaster that this is justified, why even care about fixing C?

vyodaiken 8y ago
If you could actually provide some concrete basis for that argument, it would be interesting.