5 ms·

>Undefined behavior ends up turning this into "C++ compiler generates the most efficient thing that may or may not correlate with what you intended" What norma

>Undefined behavior ends up turning this into "C++ compiler generates the most efficient thing that may or may not correlate with what you intended" What normal C++ syntax are you referring to that generates undefined behavior?

jzwinck 5y ago
For example, incrementing an int until it overflows.
- passivate 5y ago
  My point was what are examples of normal C++ code where the language obviously deviates from the intention of the programmer and screws them over with undefined behavior. I don't see how any programmer can "intend" to use a data-type assuming an infinite range - or assuming specific wrapping behavior that was never guaranteed to them by the language. If a programmer is unaware that language data types have finite ranges and/or specific wrapping behavior then that is a problem that can be easily solved with training.
  - ModernMech 5y ago
    > If a programmer is unaware that language data types have finite ranges and/or specific wrapping behavior then that is a problem that can be easily solved with training. The thing is that everyone recognizes this and yet entire categories of bugs that are easily caught with appropriate language design and tooling nonetheless persist in C and C++. Yes, a programmer who does not understand the footguns involved with e.g. integer overflows can be trained to understand them and avoid them. But for every one you train, there will always be another novice programming ready and willing to use the footguns. And even if you do train every last one and every new one, they still have to practice discipline and be vigilant forever more to avoid these problems. Discipline doesn't scale. It's far better to enforce good behavior at the language level, rather than expecting you'll be able to train your way around these issues.
    - passivate 5y ago
      It will be difficult to program in any language if one believes that you can store an infinite number series in a fixed data type like int. It's like thinking a hard disk can store infinite data.
      - Etherlord87 5y ago
        Yes, but the problem in a different language comes down to an error message. In C you have UB and it's not defined what you have to expect, which makes it harder to find the cause of an error once it happens.
  - overgard 5y ago
    Leaving out UB, what is the size of an "int"? Any of: 16bit, 32bit, 64bit is correct. However I'm absolutely certain the code you write for an 8bit microcontroller is a lot different from your 64bit server, so why is this language pretending to scale like that? Yeah you can now write "uint8_t" instead of "char", but the point is that the ecosystem is a landmine and all the maimed people are shamed with "you should have read the 400 page map" At risk of sounding crazy what if we just took this undefined behavior and just defined it? Theres like maybe 100 cpu ISAs in the world we care about, and the web and the transitory nature of tech had made legacy support kinda useless. Life would probably be simpler if we just said "ok heres how these constructs work" and just removed the ambiguity
    - passivate 5y ago
      > Yeah you can now write "uint8_t" instead of "char", but the point is that the ecosystem is a landmine and all the maimed people are shamed with "you should have read the 400 page map" You're criticizing syntax from 30 years ago. Yes, the backwards compatibility (to me) is a BONUS. I would not want to junk working code that I paid for, just so I can use uint8_t. You have the option to begin a slow migration of old code into more modern code - without paying the massive cost of re-writing from scratch. I guess I am not able to connect with your criticism since it is far removed from my original point - What are examples of normal C++ syntax where the language screws you over with UB? Its a honest question - I'm not longer a C++ dev but I am curious to know what people are talking about.
      - overgard 5y ago
        I'm not against backwards compatibility, I just think leaving primitive sizes up to shrug emoji wasn't brilliant Man reasons where C syntax has left me out to dry? Well I once spent a week on a deadline debugging a pointer overflow, where it only happened when the game was fullscreen and not debuggable (circa 2005). Even modern C++ is awful though. I fixed a bug a while ago where an "auto&" was just an "auto", and caused the entire scene graph to get copied and then crash.
overgard 5y ago
Have you ever worked in a code base that was clean of UB? If so, are you SURE? By the way this is not a question I ask of any other language on the planet. The fact is, you have to carry the cognitive overhead of UB even if you write everything correctly, because in the world of C the compiler it can almost be considered an antagonist if it can get 5% faster.
- passivate 5y ago
  It would be easier to settle these arguments with code rather than opinions.
  - tialaramex 5y ago
    It would. Do you have some non-trivial bodies of C++ code that you feel don't exhibit any undefined behaviour ?
    - passivate 5y ago
      Yes, all of the code that I've written over the past 15 years. The last I worked on it, I had zero bugs related to UB. The people who paid me own the code. In any case, its completely bizarre that I'm asking someone to backup their claim, which I didn't agree with, and you're asking me to prove a negative. I don't know what your intention is.
      - overgard 5y ago
        No offense but that sounds like BS to me. I'd love to see the result of a static analysis tool on your code base
        passivate 5y ago
        Why is that BS? I prioritized and fixed all major bugs, including UB bugs and tje last I worked on it I had zero outstanding bugs of that kind. I'm not saying I never had any bugs in my code. I don't know how I am supposed to be omniscient about bugs I don't know about.
Etherlord87 5y ago
> What normal C++ syntax are you referring to that generates undefined behavior? If you have a function that takes two arguments and prints both, and you supply arguments like so: my_func(a++, a) You just generated undefined behavior, because the order in which the expressions inside the function call are evaluated, is not guaranteed (keep in mind the comma inside the function call is not a comma operator, which is one of I think 4 operators that actually does guarantee the evaluation order). You may say it's up to the programmer to know such rules of the programming language, however there's a lot of such rules which makes programming in C++ like walking through a minefield - yes, at some point you learned where the mines are, but you're supposed to remember about them at all times or you risk stepping on one. Another issue is how the compiler reacts to this UB - usually in a programming language you'd expect that perhaps in one version the arguments are evaluated from left to right, and in another from right to left, or perhaps in some other version it depends on current program state or some other seemingly random factors. However in C++ UB means that everything can happen, for example, the compiler may no-op the entire function call (or worse, the time-space may collapse) I consider this to actually be an advantage of C++ - there's a lot on the programmer's shoulders, but that gives more possibilities to the compilers (to optimize). I'm not an expert on C++ but that's my understanding. See also: https://news.ycombinator.com/item?id=28449461 https://news.ycombinator.com/item?id=28449461
- passivate 5y ago
  An expression like my_func(a++, a) is confusing on all fronts - the intention isn't clear for the compiler, for the code reviewer, for the programmer themselves when they read it 5 years from now, for the next-in-line bloke who gets handed this code to maintain it, etc. My point was about whether C++ screws you over with UB when the programmers intention can be argued to be obvious. I don't think it does. But I will stand corrected if someone can show me what they're talking about. It seems like people are making this into a discussion about C++ being a difficult language to learn - which I am not defending.
  - Etherlord87 5y ago
    > My point was about whether C++ screws you over with UB when the programmers intention can be argued to be obvious. Incrementing a number is obvious and results with UB if incremented past the maximum. Since you get no guarantee whatsoever how the UB will be handled (hence the joke with the end of the space-time, or nasal demons etc.), by my understanding (that I think many experts share), it can indeed screw you up. Of course you may say a programmer should expect this to happen and so it's just a bug - every UB is. > It seems like people are making this into a discussion about C++ being a difficult language to learn I think it's more than that. Even assuming that you never caused UB yourself, you can still work on someone else's code with UB and need to debug it. So C++ is hard to learn AND use.
yoyonamite 5y ago
I don't really work on C or C++ code outside of some stuff that I do for fun, but here are some examples I've seen mentioned when this topic comes up: https://people.csail.mit.edu/nickolai/papers/wang-undef-2012-08-21.pdf https://people.csail.mit.edu/nickolai/papers/wang-undef-2012... https://lwn.net/Articles/575563/ https://lwn.net/Articles/575563/

jzwinck 5y ago

For example, incrementing an int until it overflows.

passivate 5y ago
My point was what are examples of normal C++ code where the language obviously deviates from the intention of the programmer and screws them over with undefined behavior. I don't see how any programmer can "intend" to use a data-type assuming an infinite range - or assuming specific wrapping behavior that was never guaranteed to them by the language. If a programmer is unaware that language data types have finite ranges and/or specific wrapping behavior then that is a problem that can be easily solved with training.
- ModernMech 5y ago
  > If a programmer is unaware that language data types have finite ranges and/or specific wrapping behavior then that is a problem that can be easily solved with training. The thing is that everyone recognizes this and yet entire categories of bugs that are easily caught with appropriate language design and tooling nonetheless persist in C and C++. Yes, a programmer who does not understand the footguns involved with e.g. integer overflows can be trained to understand them and avoid them. But for every one you train, there will always be another novice programming ready and willing to use the footguns. And even if you do train every last one and every new one, they still have to practice discipline and be vigilant forever more to avoid these problems. Discipline doesn't scale. It's far better to enforce good behavior at the language level, rather than expecting you'll be able to train your way around these issues.
  - passivate 5y ago
    It will be difficult to program in any language if one believes that you can store an infinite number series in a fixed data type like int. It's like thinking a hard disk can store infinite data.
    - Etherlord87 5y ago
      Yes, but the problem in a different language comes down to an error message. In C you have UB and it's not defined what you have to expect, which makes it harder to find the cause of an error once it happens.
- overgard 5y ago
  Leaving out UB, what is the size of an "int"? Any of: 16bit, 32bit, 64bit is correct. However I'm absolutely certain the code you write for an 8bit microcontroller is a lot different from your 64bit server, so why is this language pretending to scale like that? Yeah you can now write "uint8_t" instead of "char", but the point is that the ecosystem is a landmine and all the maimed people are shamed with "you should have read the 400 page map" At risk of sounding crazy what if we just took this undefined behavior and just defined it? Theres like maybe 100 cpu ISAs in the world we care about, and the web and the transitory nature of tech had made legacy support kinda useless. Life would probably be simpler if we just said "ok heres how these constructs work" and just removed the ambiguity
  - passivate 5y ago
    > Yeah you can now write "uint8_t" instead of "char", but the point is that the ecosystem is a landmine and all the maimed people are shamed with "you should have read the 400 page map" You're criticizing syntax from 30 years ago. Yes, the backwards compatibility (to me) is a BONUS. I would not want to junk working code that I paid for, just so I can use uint8_t. You have the option to begin a slow migration of old code into more modern code - without paying the massive cost of re-writing from scratch. I guess I am not able to connect with your criticism since it is far removed from my original point - What are examples of normal C++ syntax where the language screws you over with UB? Its a honest question - I'm not longer a C++ dev but I am curious to know what people are talking about.
    - overgard 5y ago
      I'm not against backwards compatibility, I just think leaving primitive sizes up to shrug emoji wasn't brilliant Man reasons where C syntax has left me out to dry? Well I once spent a week on a deadline debugging a pointer overflow, where it only happened when the game was fullscreen and not debuggable (circa 2005). Even modern C++ is awful though. I fixed a bug a while ago where an "auto&" was just an "auto", and caused the entire scene graph to get copied and then crash.

overgard 5y ago

Have you ever worked in a code base that was clean of UB? If so, are you SURE? By the way this is not a question I ask of any other language on the planet. The fact is, you have to carry the cognitive overhead of UB even if you write everything correctly, because in the world of C the compiler it can almost be considered an antagonist if it can get 5% faster.

passivate 5y ago
It would be easier to settle these arguments with code rather than opinions.
- tialaramex 5y ago
  It would. Do you have some non-trivial bodies of C++ code that you feel don't exhibit any undefined behaviour ?
  - passivate 5y ago
    Yes, all of the code that I've written over the past 15 years. The last I worked on it, I had zero bugs related to UB. The people who paid me own the code. In any case, its completely bizarre that I'm asking someone to backup their claim, which I didn't agree with, and you're asking me to prove a negative. I don't know what your intention is.
    - overgard 5y ago
      No offense but that sounds like BS to me. I'd love to see the result of a static analysis tool on your code base
      - passivate 5y ago
        Why is that BS? I prioritized and fixed all major bugs, including UB bugs and tje last I worked on it I had zero outstanding bugs of that kind. I'm not saying I never had any bugs in my code. I don't know how I am supposed to be omniscient about bugs I don't know about.

Etherlord87 5y ago

> What normal C++ syntax are you referring to that generates undefined behavior? If you have a function that takes two arguments and prints both, and you supply arguments like so: my_func(a++, a) You just generated undefined behavior, because the order in which the expressions inside the function call are evaluated, is not guaranteed (keep in mind the comma inside the function call is not a comma operator, which is one of I think 4 operators that actually does guarantee the evaluation order). You may say it's up to the programmer to know such rules of the programming language, however there's a lot of such rules which makes programming in C++ like walking through a minefield - yes, at some point you learned where the mines are, but you're supposed to remember about them at all times or you risk stepping on one. Another issue is how the compiler reacts to this UB - usually in a programming language you'd expect that perhaps in one version the arguments are evaluated from left to right, and in another from right to left, or perhaps in some other version it depends on current program state or some other seemingly random factors. However in C++ UB means that everything can happen, for example, the compiler may no-op the entire function call (or worse, the time-space may collapse) I consider this to actually be an advantage of C++ - there's a lot on the programmer's shoulders, but that gives more possibilities to the compilers (to optimize). I'm not an expert on C++ but that's my understanding. See also: https://news.ycombinator.com/item?id=28449461 https://news.ycombinator.com/item?id=28449461

passivate 5y ago
An expression like my_func(a++, a) is confusing on all fronts - the intention isn't clear for the compiler, for the code reviewer, for the programmer themselves when they read it 5 years from now, for the next-in-line bloke who gets handed this code to maintain it, etc. My point was about whether C++ screws you over with UB when the programmers intention can be argued to be obvious. I don't think it does. But I will stand corrected if someone can show me what they're talking about. It seems like people are making this into a discussion about C++ being a difficult language to learn - which I am not defending.
- Etherlord87 5y ago
  > My point was about whether C++ screws you over with UB when the programmers intention can be argued to be obvious. Incrementing a number is obvious and results with UB if incremented past the maximum. Since you get no guarantee whatsoever how the UB will be handled (hence the joke with the end of the space-time, or nasal demons etc.), by my understanding (that I think many experts share), it can indeed screw you up. Of course you may say a programmer should expect this to happen and so it's just a bug - every UB is. > It seems like people are making this into a discussion about C++ being a difficult language to learn I think it's more than that. Even assuming that you never caused UB yourself, you can still work on someone else's code with UB and need to debug it. So C++ is hard to learn AND use.

yoyonamite 5y ago

I don't really work on C or C++ code outside of some stuff that I do for fun, but here are some examples I've seen mentioned when this topic comes up: https://people.csail.mit.edu/nickolai/papers/wang-undef-2012-08-21.pdf https://people.csail.mit.edu/nickolai/papers/wang-undef-2012... https://lwn.net/Articles/575563/ https://lwn.net/Articles/575563/