3 ms·

As much as I agree with the intro, these examples aren't good and the overall article is just a veil for pushing LLM coding.

boxed 5mo ago
Not good how? Are they TRUE? If so that's super bad.
- IshKebab 5mo ago
  They are true but I agree it's not a great article. C has an unending list of UB and given the title I was expecting a more comprehensive survey, but they actually just picked a few that are both fairly well known and not very interesting.
  - thomashabets2 5mo ago
    Author here. As I stated: > The following is not an attempt at enumerating all the UB in the world. It’s merely making the case that UB is everywhere, and if nobody can do it right, how is it even fair to blame the programmer? My point is that ALL nontrivial C/C++ code has UB. It's about that point, not about how to avoid it. Because you can't.
- HelloNurse 5mo ago
  Some of the examples are somewhat formally true in theory and bullshit in practice; some are quite hallucinatory. - Creating a potentially troublesome misaligned int pointer is a precisely localized and completely explicit user mistake, not something that just happens because it's C. - Passing signed char to character classification functions that expect an unsigned char (disguised as an int) is a very specific dumb user error. The C standard could specify that all negative inputs, including EOF and invalid signed char values, are classified as not belonging to the character class, but I doubt the current undefined behaviour in isxdigit() etc. implementations ever went beyond accepting invalid inputs. - Casting floating point values to integer values in general requires taking care of whether the FP values are small enough to be represented and what to do with NaN and Inf values: not the language's responsibility. C offers a toolbox of tests, not ready-made application specific error handling. - Expecting C to handle "address zero" in physical memory in ways that conflict with NULL in source code denotes a complete lack of understanding of what a program is. Where stuff in an executable is loaded in memory, in the rare cases when it matters, can surely be affected with platform specific extensions, possibly at the level of linker commands with nothing appearing in the C source code.
  - thomashabets2 5mo ago
    Author here. So I see your counter points are all "so just don't do that, then". And the point of my post is that this particular "just don't do that, then" has never been achieved by humans. If if there's no example of a program without these bugs in a language, then I do think it's fair to blame the language. A knife with 16 blades and no handle. > Expecting C to handle "address zero" in physical memory in ways that conflict with NULL in source code denotes a complete lack of understanding of what a program is. Like the post says, it's rare that programmers actually want a pointer to memory address zero. But in my experience most programmers who even encounter that have this "complete lack of understanding", as you put it.
    - HelloNurse 5mo ago
      "Just don't do that" is the correct approach to errors, even when they are easy to overlook and the programming language provides many opportunities for mistakes. For example, you seem to underestimate how wrong placing negative values in a signed char is: ordinary character encodings do not use negative codes, so either those negative values are not characters and they have no business being treated as such, or something strange and experimental is going on.
      - dminik 5mo ago
        Just don't fall bro. It's that easy. No railings required.
      - thomashabets2 5mo ago
        > "Just don't do that" is the correct approach to errors We have 54 years of empirical data that literally nobody can follow this approach and reach UB-freeness. To stick to the plan is more like the in-debt gambler who just needs to work their system for a little longer, and they'll become rich. By this logic we don't need any traffic rules other than "just don't crash or hit anyone". And we can aspire to an absolute dictatorship, all we need to do is "just" choose the benevolent one. Of course we should always try to not make mistakes. But given more than half a century of empirical data that nobody has been able to avoid UB, ever, it takes quite some hubris to say "but it might work for us". > you seem to underestimate how wrong placing negative values in a signed char is Shrug. You don't make that mistake. There are thousands of mistakes like it, especially in C or C++. Of course "don't do that". That is not the same as "So just don't do that!". The former is good advice. The latter is one of a million rules, and to expect even experts (see OpenBSD) to never make a mistake is unrealistic to say the least. You may even have spotted the UB in https://pooladkhay.com/posts/first-kernel-patch/ https://pooladkhay.com/posts/first-kernel-patch/. But you would not spot all of them. Nobody in history has.
gblargg 5mo ago
Agreed. One after another these are standard things you avoid when writing portable code (or don't need, like accessing the object at address 0). They come across like from someone who wants to write whatever they want and have it work the same on everything. To make it into a language that allows this would remove its advantage of being able to write to the platform when you want to.

boxed 5mo ago

Not good how? Are they TRUE? If so that's super bad.

IshKebab 5mo ago
They are true but I agree it's not a great article. C has an unending list of UB and given the title I was expecting a more comprehensive survey, but they actually just picked a few that are both fairly well known and not very interesting.
- thomashabets2 5mo ago
  Author here. As I stated: > The following is not an attempt at enumerating all the UB in the world. It’s merely making the case that UB is everywhere, and if nobody can do it right, how is it even fair to blame the programmer? My point is that ALL nontrivial C/C++ code has UB. It's about that point, not about how to avoid it. Because you can't.
HelloNurse 5mo ago
Some of the examples are somewhat formally true in theory and bullshit in practice; some are quite hallucinatory. - Creating a potentially troublesome misaligned int pointer is a precisely localized and completely explicit user mistake, not something that just happens because it's C. - Passing signed char to character classification functions that expect an unsigned char (disguised as an int) is a very specific dumb user error. The C standard could specify that all negative inputs, including EOF and invalid signed char values, are classified as not belonging to the character class, but I doubt the current undefined behaviour in isxdigit() etc. implementations ever went beyond accepting invalid inputs. - Casting floating point values to integer values in general requires taking care of whether the FP values are small enough to be represented and what to do with NaN and Inf values: not the language's responsibility. C offers a toolbox of tests, not ready-made application specific error handling. - Expecting C to handle "address zero" in physical memory in ways that conflict with NULL in source code denotes a complete lack of understanding of what a program is. Where stuff in an executable is loaded in memory, in the rare cases when it matters, can surely be affected with platform specific extensions, possibly at the level of linker commands with nothing appearing in the C source code.
- thomashabets2 5mo ago
  Author here. So I see your counter points are all "so just don't do that, then". And the point of my post is that this particular "just don't do that, then" has never been achieved by humans. If if there's no example of a program without these bugs in a language, then I do think it's fair to blame the language. A knife with 16 blades and no handle. > Expecting C to handle "address zero" in physical memory in ways that conflict with NULL in source code denotes a complete lack of understanding of what a program is. Like the post says, it's rare that programmers actually want a pointer to memory address zero. But in my experience most programmers who even encounter that have this "complete lack of understanding", as you put it.
  - HelloNurse 5mo ago
    "Just don't do that" is the correct approach to errors, even when they are easy to overlook and the programming language provides many opportunities for mistakes. For example, you seem to underestimate how wrong placing negative values in a signed char is: ordinary character encodings do not use negative codes, so either those negative values are not characters and they have no business being treated as such, or something strange and experimental is going on.
    - dminik 5mo ago
      Just don't fall bro. It's that easy. No railings required.
    - thomashabets2 5mo ago
      > "Just don't do that" is the correct approach to errors We have 54 years of empirical data that literally nobody can follow this approach and reach UB-freeness. To stick to the plan is more like the in-debt gambler who just needs to work their system for a little longer, and they'll become rich. By this logic we don't need any traffic rules other than "just don't crash or hit anyone". And we can aspire to an absolute dictatorship, all we need to do is "just" choose the benevolent one. Of course we should always try to not make mistakes. But given more than half a century of empirical data that nobody has been able to avoid UB, ever, it takes quite some hubris to say "but it might work for us". > you seem to underestimate how wrong placing negative values in a signed char is Shrug. You don't make that mistake. There are thousands of mistakes like it, especially in C or C++. Of course "don't do that". That is not the same as "So just don't do that!". The former is good advice. The latter is one of a million rules, and to expect even experts (see OpenBSD) to never make a mistake is unrealistic to say the least. You may even have spotted the UB in https://pooladkhay.com/posts/first-kernel-patch/ https://pooladkhay.com/posts/first-kernel-patch/. But you would not spot all of them. Nobody in history has.

gblargg 5mo ago

Agreed. One after another these are standard things you avoid when writing portable code (or don't need, like accessing the object at address 0). They come across like from someone who wants to write whatever they want and have it work the same on everything. To make it into a language that allows this would remove its advantage of being able to write to the platform when you want to.