5 ms·

Care to share an example?

capitainenemo 2y ago
sorting floats with NaN ? almost anything involving threading and mutation where people either don't realise how important locks are, or don't realise their code has suddenly been threaded?
masfuerte 2y ago
int average(int x, int y) { return (x+y)/2; }
- throwaway2037 2y ago
  I assume you are hinting at 'int' is signed here? And, that signed overflow is UB in C? Real question: Ignoring what the ISO C language spec says, are there any modern hardware platforms (say: ARM64 and X86-64) that do not use two's complement to implement signed integers? I don't know any. As I understand, two's complement correctly supports overflow for signed arithmetic. I might be old, but more than 10 years ago, hardly anyone talked about UB in C and C++ programming. In the last 10 years, it is all the rage, but seems to add very little to the conversation. For example, if you program C or C++ with the Win32 API, there are loads of weird UB-ish things that seem to work fine.
  - steveklabnik 2y ago
    > Ignoring what the ISO C language spec says, are there any modern hardware platforms (say: ARM64 and X86-64) that do not use two's complement to implement signed integers? This is not how compilers work. Optimization happens based on language semantics, not on what platforms do.
  - jandrewrogers 2y ago
    At least in recent C++ standards, integers are defined as two’s complement. As a practical matter what hardware like that may still exist doesn’t have a modern C++ compiler, rendering it a moot point. UB in C is often found where different real hardware architectures had incompatible behavior. Rather than biasing the language for or against different architectures they left it to the compiler to figure out how to optimize for the cases where instruction behavior diverge. This is still true on current architectures e.g. shift overflow behavior which is why shift overflow is UB.
  - oneshtein 2y ago
    AI rewrote to avoid undefined behavior: int average(int x, int y) { long sum = (long)x + y; if(sum > INT_MAX || sum < INT_MIN) return -1; // or any value that indicates an error/overflow return (int)(sum / 2); }
    - Jaxan 2y ago
      I’m not convinced that solution is much better. It can be improved to x/2 + y/2 (which still gives the wrong answer if both inputs are odd).
    - josefx 2y ago
      > long sum = (long)x + y; There is no guarantee that sizeof(long) > sizeof(int), in fact the GNU libc documentation states that int and long have the same size on the majority of supported platforms. https://www.gnu.org/software/libc/manual/html_node/Range-of-Type.html https://www.gnu.org/software/libc/manual/html_node/Range-of-... > return -1; // or any value that indicates an error/overflow -1 is a perfectly valid average for various inputs. You could return the larger type to encode an error value that is not a valid output or just output the error and average in two distinct variables. AI and C seem like a match made in hell.
      - cesarb 2y ago
        > There is no guarantee that sizeof(long) > sizeof(int), in fact the GNU libc documentation states that int and long have the same size on the majority of supported platforms. That used to be the case for 32-bit platforms, but most 64-bit platforms in which GNU libc runs use the LP64 model, which has 32-bit int and 64-bit long. That documentation seems to be a bit outdated. (One notable 64-bit platform which uses 32-bit for both int and long is Microsoft Windows, but that's not one of the target platforms for GNU libc.)
    - throwaway2037 2y ago
      I don't know why this answer was downvoted. It adds valuable information to this discussion. Yes, I know that someone already pointed out that sizeof(int) is not guaranteed on all platforms to be smaller than sizeof(long). Meh. Just change the type to long long, and it works well.
- uecker 2y ago
  But this is also easy to protect against if you use the tools available to C programmers. It is part of the Rust hype that we would be completely helpless here, but this is far from the truth.
- uecker 2y ago
  You can tell a C compiler to trap or wrap around on overflow, or you use checked arithmetic to test explicitly for overflow.
pests 2y ago
https://www.ioccc.org/years.html https://www.ioccc.org/years.html

sorting floats with NaN ? almost anything involving threading and mutation where people either don't realise how important locks are, or don't realise their code has suddenly been threaded?

masfuerte 2y ago

int average(int x, int y) { return (x+y)/2; }

throwaway2037 2y ago
I assume you are hinting at 'int' is signed here? And, that signed overflow is UB in C? Real question: Ignoring what the ISO C language spec says, are there any modern hardware platforms (say: ARM64 and X86-64) that do not use two's complement to implement signed integers? I don't know any. As I understand, two's complement correctly supports overflow for signed arithmetic. I might be old, but more than 10 years ago, hardly anyone talked about UB in C and C++ programming. In the last 10 years, it is all the rage, but seems to add very little to the conversation. For example, if you program C or C++ with the Win32 API, there are loads of weird UB-ish things that seem to work fine.
- steveklabnik 2y ago
  > Ignoring what the ISO C language spec says, are there any modern hardware platforms (say: ARM64 and X86-64) that do not use two's complement to implement signed integers? This is not how compilers work. Optimization happens based on language semantics, not on what platforms do.
- jandrewrogers 2y ago
  At least in recent C++ standards, integers are defined as two’s complement. As a practical matter what hardware like that may still exist doesn’t have a modern C++ compiler, rendering it a moot point. UB in C is often found where different real hardware architectures had incompatible behavior. Rather than biasing the language for or against different architectures they left it to the compiler to figure out how to optimize for the cases where instruction behavior diverge. This is still true on current architectures e.g. shift overflow behavior which is why shift overflow is UB.
- oneshtein 2y ago
  AI rewrote to avoid undefined behavior: int average(int x, int y) { long sum = (long)x + y; if(sum > INT_MAX || sum < INT_MIN) return -1; // or any value that indicates an error/overflow return (int)(sum / 2); }
  - Jaxan 2y ago
    I’m not convinced that solution is much better. It can be improved to x/2 + y/2 (which still gives the wrong answer if both inputs are odd).
  - josefx 2y ago
    > long sum = (long)x + y; There is no guarantee that sizeof(long) > sizeof(int), in fact the GNU libc documentation states that int and long have the same size on the majority of supported platforms. https://www.gnu.org/software/libc/manual/html_node/Range-of-Type.html https://www.gnu.org/software/libc/manual/html_node/Range-of-... > return -1; // or any value that indicates an error/overflow -1 is a perfectly valid average for various inputs. You could return the larger type to encode an error value that is not a valid output or just output the error and average in two distinct variables. AI and C seem like a match made in hell.
    - cesarb 2y ago
      > There is no guarantee that sizeof(long) > sizeof(int), in fact the GNU libc documentation states that int and long have the same size on the majority of supported platforms. That used to be the case for 32-bit platforms, but most 64-bit platforms in which GNU libc runs use the LP64 model, which has 32-bit int and 64-bit long. That documentation seems to be a bit outdated. (One notable 64-bit platform which uses 32-bit for both int and long is Microsoft Windows, but that's not one of the target platforms for GNU libc.)
  - throwaway2037 2y ago
    I don't know why this answer was downvoted. It adds valuable information to this discussion. Yes, I know that someone already pointed out that sizeof(int) is not guaranteed on all platforms to be smaller than sizeof(long). Meh. Just change the type to long long, and it works well.
uecker 2y ago
But this is also easy to protect against if you use the tools available to C programmers. It is part of the Rust hype that we would be completely helpless here, but this is far from the truth.
uecker 2y ago
You can tell a C compiler to trap or wrap around on overflow, or you use checked arithmetic to test explicitly for overflow.

pests 2y ago

https://www.ioccc.org/years.html https://www.ioccc.org/years.html