3 ms·

For example checking for signed overflow must be done carefully: https://stackoverflow.com/questions/3944505/detecting-signed-overflow-in-c-c https://stackover

by rini17 6y ago

For example checking for signed overflow must be done carefully: https://stackoverflow.com/questions/3944505/detecting-signed-overflow-in-c-c https://stackoverflow.com/questions/3944505/detecting-signed... "Design philosophy"...oh please! C was designed for transistor- and memory- scarce microcomputers. Nowadays there is defacto supercomputer in every phone and runtime bounds checks are cheap. Moreover, allowing CPU to know the size of memory chunk pointed to could enable optimization which would make the code actually faster (not even talking about security benefits). But you C programmers insist tooth an nail against that...

MaxBarraclough 6y ago
> For example checking for signed overflow must be done carefully: Right, but we're talking about a simple bounds check. There should be no need for any arithmetic, just comparison. > "Design philosophy"...oh please! C was designed for transistor- and memory- scarce microcomputers. Right. Hence its design philosophy. > Nowadays there is defacto supercomputer in every phone and runtime bounds checks are cheap. Cheap, but perhaps not cheap enough to dismiss entirely. Bounds checking costs a few percent of performance [0], enough to put some people off in some domains such as in the kernel. It's a pity C makes it difficult to automate just about any kind of check. Checking whether a pointer overruns a buffer that was returned by free, for instance, requires quite a bit of cleverness, as the system has to track the size of the allocated block. You have to rely on optional compiler features, elaborate static analysis tools (often proprietary and expensive), and dynamic analysis tools like Valgrind. Ada on the other hand enables all sorts of runtime checks by default, but it's easy to switch them all off if you're sure. > CPU to know the size of memory chunk pointed to could enable optimization which would make the code actually faster (not even talking about security benefits) What kind of optimisation do you have in mind? Pre-caching? > But you C programmers insist tooth an nail against that... 'Fat pointers' of this sort have been tried with the C language [1] but I can't see the committee adding them to the standard. Part of C's virtue is that it's extremely slow moving. I'm not advocating continued widespread use of C though. I hope safe-but-fast languages like Rust do well. We all pay a price for the problems associated with C and, perhaps to a lesser extent, C++. For what it's worth I haven't written serious C or C++ code for a long time. [0] https://doi.org/10.1145/1294325.1294343 https://doi.org/10.1145/1294325.1294343 (An old source admittedly) [1] http://libcello.org/learn/a-fat-pointer-library http://libcello.org/learn/a-fat-pointer-library
- rini17 6y ago
  > What kind of optimisation do you have in mind? Pre-caching? All kinds of branch prediction. If CPU knew it is iterating over a fat pointer, it could safely internally unroll the loop or even vectorize the operation. There are so many easy tricks based on runtime information used by JIT languages, yet not implemented in silicon (or only speculatively) because of C legacy.
  - MaxBarraclough 6y ago
    > If CPU knew it is iterating over a fat pointer, it could safely internally unroll the loop or even vectorize the operation. That should already be possible with the C custom of passing an array's size alongside the array pointer. As I understand it modern CPUs have very sophisticated loop-detection for doing precisely this kind of thing.
    - rini17 6y ago
      Now we're back to square one: C Compiler has to resort to UB to optimize many kinds "for" loops, including basic stuff like extracting the iteration count - examples in today's discussion. It then tries to emit something that CPU speculative prediction unit can successfully pick up. It is so hard for programmer to unequivocally signal the intent like "we're working with this here chunk of memory malloc'd with this size and nothing ever beyond it and let me know if this is violated". I don't understand why this state of affairs is not universally considered sordid but it's handwaved "just be aware of UB and pass the size along and it will be well"...
      - MaxBarraclough 6y ago
        > C Compiler has to resort to UB to optimize many kinds "for" loops The compiler is always permitted to assume the absence of UB. This is the case no matter what your C code is doing, and you're never further than one expression away from UB. > It is so hard for programmer to unequivocally signal the intent like "we're working with this here chunk of memory malloc'd with this size and nothing ever beyond it and let me know if this is violated". Indeed, and C pretty much stands alone here. In just about every other language, there's some automated means of keeping track of the size of an allocated block. Even C++ has this in std::array. The only exceptions I can think of are assembly, if that counts, and Forth. > I don't understand why this state of affairs is not universally considered sordid but it's handwaved "just be aware of UB and pass the size along and it will be well"... You're not alone in thinking this is a particularly reckless design decision in C. The great Walter Bright, designer of the D language and also a HackerNews regular, wrote a short article on this in 2009, called C's Biggest Mistake. [0] He even suggested a fix, of adding the option of fat pointers into C. I don't think the committee is going to adopt it though. I recall reading somewhere a snarky take on this: A foundational principle of the C programming language is that the programmer is always right, even when they are wrong. [0] https://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625 https://www.drdobbs.com/architecture-and-design/cs-biggest-m... , see also discussion at https://news.ycombinator.com/item?id=1014533 https://news.ycombinator.com/item?id=1014533 , https://old.reddit.com/r/C_Programming/90uq7c/ https://old.reddit.com/r/C_Programming/90uq7c/

by rini17 6y ago

MaxBarraclough 6y ago

> For example checking for signed overflow must be done carefully: Right, but we're talking about a simple bounds check. There should be no need for any arithmetic, just comparison. > "Design philosophy"...oh please! C was designed for transistor- and memory- scarce microcomputers. Right. Hence its design philosophy. > Nowadays there is defacto supercomputer in every phone and runtime bounds checks are cheap. Cheap, but perhaps not cheap enough to dismiss entirely. Bounds checking costs a few percent of performance [0], enough to put some people off in some domains such as in the kernel. It's a pity C makes it difficult to automate just about any kind of check. Checking whether a pointer overruns a buffer that was returned by free, for instance, requires quite a bit of cleverness, as the system has to track the size of the allocated block. You have to rely on optional compiler features, elaborate static analysis tools (often proprietary and expensive), and dynamic analysis tools like Valgrind. Ada on the other hand enables all sorts of runtime checks by default, but it's easy to switch them all off if you're sure. > CPU to know the size of memory chunk pointed to could enable optimization which would make the code actually faster (not even talking about security benefits) What kind of optimisation do you have in mind? Pre-caching? > But you C programmers insist tooth an nail against that... 'Fat pointers' of this sort have been tried with the C language [1] but I can't see the committee adding them to the standard. Part of C's virtue is that it's extremely slow moving. I'm not advocating continued widespread use of C though. I hope safe-but-fast languages like Rust do well. We all pay a price for the problems associated with C and, perhaps to a lesser extent, C++. For what it's worth I haven't written serious C or C++ code for a long time. [0] https://doi.org/10.1145/1294325.1294343 https://doi.org/10.1145/1294325.1294343 (An old source admittedly) [1] http://libcello.org/learn/a-fat-pointer-library http://libcello.org/learn/a-fat-pointer-library

rini17 6y ago
> What kind of optimisation do you have in mind? Pre-caching? All kinds of branch prediction. If CPU knew it is iterating over a fat pointer, it could safely internally unroll the loop or even vectorize the operation. There are so many easy tricks based on runtime information used by JIT languages, yet not implemented in silicon (or only speculatively) because of C legacy.
- MaxBarraclough 6y ago
  > If CPU knew it is iterating over a fat pointer, it could safely internally unroll the loop or even vectorize the operation. That should already be possible with the C custom of passing an array's size alongside the array pointer. As I understand it modern CPUs have very sophisticated loop-detection for doing precisely this kind of thing.
  - rini17 6y ago
    Now we're back to square one: C Compiler has to resort to UB to optimize many kinds "for" loops, including basic stuff like extracting the iteration count - examples in today's discussion. It then tries to emit something that CPU speculative prediction unit can successfully pick up. It is so hard for programmer to unequivocally signal the intent like "we're working with this here chunk of memory malloc'd with this size and nothing ever beyond it and let me know if this is violated". I don't understand why this state of affairs is not universally considered sordid but it's handwaved "just be aware of UB and pass the size along and it will be well"...
    - MaxBarraclough 6y ago
      > C Compiler has to resort to UB to optimize many kinds "for" loops The compiler is always permitted to assume the absence of UB. This is the case no matter what your C code is doing, and you're never further than one expression away from UB. > It is so hard for programmer to unequivocally signal the intent like "we're working with this here chunk of memory malloc'd with this size and nothing ever beyond it and let me know if this is violated". Indeed, and C pretty much stands alone here. In just about every other language, there's some automated means of keeping track of the size of an allocated block. Even C++ has this in std::array. The only exceptions I can think of are assembly, if that counts, and Forth. > I don't understand why this state of affairs is not universally considered sordid but it's handwaved "just be aware of UB and pass the size along and it will be well"... You're not alone in thinking this is a particularly reckless design decision in C. The great Walter Bright, designer of the D language and also a HackerNews regular, wrote a short article on this in 2009, called C's Biggest Mistake. [0] He even suggested a fix, of adding the option of fat pointers into C. I don't think the committee is going to adopt it though. I recall reading somewhere a snarky take on this: A foundational principle of the C programming language is that the programmer is always right, even when they are wrong. [0] https://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625 https://www.drdobbs.com/architecture-and-design/cs-biggest-m... , see also discussion at https://news.ycombinator.com/item?id=1014533 https://news.ycombinator.com/item?id=1014533 , https://old.reddit.com/r/C_Programming/90uq7c/ https://old.reddit.com/r/C_Programming/90uq7c/