portability

What is the defined behavior in C for UINT_MAX + 1u ? How safe is to assume it is zero? From the standard (C11, 6.2.5/9, emphasis mine): [...] A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type . If UINT_MAX is 10 : (10 + 1) % (10 + 1) == 0 So, yes, it's safe to assume it's zero. paulsm4 It's worth emphasizing that while unsigned behavior is well-defined, signed integer overflow isn't:

Is there any guarantee by any commonly followed standard (ISO C or C++, or any of the POSIX/SUS specifications) that a variable (perhaps marked volatile), not guarded by a mutex, that is being accessed by multiple threads will become eventually consistent if it is assigned to? To provide a specific example, consider two threads sharing a variable v, with initial value zero. Thread 1: v = 1 Thread 2: while(v == 0) yield(); Is thread 2 guaranteed to terminate eventually? Or can it conceivably spin forever because the cache coherency never kicks in and makes the assignment visible in thread 2's

Background When designing binary file formats, it's generally recommended to write integers in network byte order. For that, there are macros like htonhl() . But for a format such as WAV, actually the little endian format is used. Question How do you portably write little endian values, regardless of if the CPU your code runs on is a big endian or little endian architecture? (Ideas: can the standard macros ntohl() and htonl() be used "in reverse" somehow? Or should the code just test runtime if it's running on a little or big endian CPU and choose the appropriate code path?) So the question is

Recently, I started changing some of our applications to support MS SQL Server as an alternative back end. One of the compatibility issues I ran into is the use of MySQL's CREATE TEMPORARY TABLE to create in-memory tables that hold data for very fast access during a session with no need for permanent storage. What is the equivalent in MS SQL? A requirement is that I need to be able to use the temporary table just like any other, especially JOIN it with the permanent ones. @Keith This is a common misconception: Table variables are NOT necessarily stored in memory. In fact SQL Server decides

I am writing a library that I would like to be portable. Thus, it should not depend on glibc or Microsoft extensions or anything else that is not in the standard. I have a nice hierarchy of classes derived from std::exception that I use to handle errors in logic and input. Knowing that a particular type of exception was thrown at a particular file and line number is useful, but knowing how the execution got there would be potentially much more valuable, so I have been looking at ways of acquiring the stack trace. I am aware that this data is available when building against glibc using the

I have a package that compiles and works fine on a 32-bit machine. I am now trying to get it to compile on a 64-bit machine and find the following error- error: cast from ‘void*’ to ‘int’ loses precision Is there a compiler flag to suppress these errors? or do I have to manually edit these files to avoid these casts? Reed Copsey The issue is that, in 32bits, an int (which is a 32bit integer) will hold a pointer value. When you move to 64bit, you can no longer store a pointer in an int - it isn't large enough to hold a 64bit pointer. The intptr_t type is designed for this. Your code is broken.