3 ms·

This is important. He is arguing specifically that when made explicit and opted into by the coder that UB can be useful. The issues that C and C++ have are that

by zaphar 4y ago

This is important. He is arguing specifically that when made explicit and opted into by the coder that UB can be useful. The issues that C and C++ have are that it's too easy for the developer to get opted in to UB by the compiler without knowing it.

megous 4y ago
So you just remember the relevant UBs defined in the C standard: https://gist.github.com/Earnestly/7c903f481ff9d29a3dd1 https://gist.github.com/Earnestly/7c903f481ff9d29a3dd1 There are not that many UBs in the base language. And even fewer are relevant for day to day coding. Most of it is in the std library.
- tialaramex 4y ago
  Well, it's countably many, but there are about 200 of them, so we're not even talking US states or US presidents, but more like UN member states. I remember Togo exists, but I can't point to it on a map, and if you left it off a map I wouldn't notice. So we're asking quite a lot to say people should just remember all of them and actually use this knowledge not just recite the list. And these aren't small things, they include very broad ideas, like 'object is referred to outside of its lifetime' and even just categories of deviations from the standard like 'A "shall" or "shall not" requirement that appears outside of a constraint is violated' It's impressive that they enumerated them, A+ gold stars. As I understand it WG21 (C++) is still attempting to produce a list of the Undefined Behaviours in their language - but I don't think "memorize all these vague ideas and use that knowledge when programming" is practical.
  - megous 4y ago
    Huge number of them are obscure or in the standard library. A C programmer with some experience can go through a list and ignore the C library ones, cross out the weird ones that he'd never hit anyway because he'd not even think of writing code that way, and end up with some useful compressed list of maybe 30 for day to day use that really need to be observed because they normally appear in regular code. As for the standard library, that is often irrelevant, depending on what kind of code you're writing. Bootloader or Linux kernel, some other microcontroller code? Probably not relevant. GNOME C app? Not very relevant either, because it's all wrapped by glib, etc. And even when it's relevant, docs are very quickly searchable (by function name) and pitfalls are documented there.

by zaphar 4y ago

megous 4y ago

So you just remember the relevant UBs defined in the C standard: https://gist.github.com/Earnestly/7c903f481ff9d29a3dd1 https://gist.github.com/Earnestly/7c903f481ff9d29a3dd1 There are not that many UBs in the base language. And even fewer are relevant for day to day coding. Most of it is in the std library.

tialaramex 4y ago
Well, it's countably many, but there are about 200 of them, so we're not even talking US states or US presidents, but more like UN member states. I remember Togo exists, but I can't point to it on a map, and if you left it off a map I wouldn't notice. So we're asking quite a lot to say people should just remember all of them and actually use this knowledge not just recite the list. And these aren't small things, they include very broad ideas, like 'object is referred to outside of its lifetime' and even just categories of deviations from the standard like 'A "shall" or "shall not" requirement that appears outside of a constraint is violated' It's impressive that they enumerated them, A+ gold stars. As I understand it WG21 (C++) is still attempting to produce a list of the Undefined Behaviours in their language - but I don't think "memorize all these vague ideas and use that knowledge when programming" is practical.
- megous 4y ago
  Huge number of them are obscure or in the standard library. A C programmer with some experience can go through a list and ignore the C library ones, cross out the weird ones that he'd never hit anyway because he'd not even think of writing code that way, and end up with some useful compressed list of maybe 30 for day to day use that really need to be observed because they normally appear in regular code. As for the standard library, that is often irrelevant, depending on what kind of code you're writing. Bootloader or Linux kernel, some other microcontroller code? Probably not relevant. GNOME C app? Not very relevant either, because it's all wrapped by glib, etc. And even when it's relevant, docs are very quickly searchable (by function name) and pitfalls are documented there.