11–20 of 30 posts
Earlier quoted context omitted.
Because of two's complement and the way implicit conversions work.
It is independent of the representation of negative numbers on the machine, because of the conversion rules.
Conversion rules are pretty basic, i.e. there is no conversion done on the actual value, so that's why it works: converting "-1" to an unsigned int yields MAX_UINT.
The next question: Why? (To clarify: I mean, "why do you care what the bits are set to".)
How many 'ones complement' machines exist?
Compare that to non-ASCII systems (e.g. AS/400), which are still much in use now and probably have a sizable bit of C/C++ programs running on them (besides COBOL and Java).
If you're programming for one of the more common platforms (i.e., x86, x64, ARM, PowerPC, 68k, MIPS, SPARC, VAX, 8080/Z80, 6502), you'll be safe to assume that ((unsigned)-1), ((unsigned)~0) and ~((unsigned)0) are all the same.
The "limits.h" (ISO C99 Standard) defines UINT_MAX as the maximum value for a variable of type unsigned int which is 4294967295 (0xffffffff).
"The contents of the header are given below, in alphabetical order. The minimum magnitudes shown shall be replaced by implementation-defined magnitudes with the same sign."
#define UINT_MAX 65535
Earlier quoted context omitted.
It is independent of the representation of negative numbers on the machine, because of the conversion rules.
Because of two's complement, "-1" as a signed int/long is internally represented with all bits set to 1. Conversion rules are pretty basic, i.e. there is no conversion done on the actual value, so that's why it works: converting "-1" to an unsigned int yields MAX_UINT.
unsigned int flags = -1;
The next question: Why? (To clarify: I mean, "why do you care what the bits are set to".)
If you meant "why worry about bits, you should be dealing with values", then there are plenty of cases where that isn't true. Lots of programs (e.g. embedded programs) have to deal with actual bits, not with the values themselves. Just as an example, flags.
(I don't know if this is what you meant, so apologies if I misunderstood your question.)
The "limits.h" (ISO C99 Standard) defines UINT_MAX as the maximum value for a variable of type unsigned int which is 4294967295 (0xffffffff).
Sigh : "The contents of the header are given below, in alphabetical order. The minimum magnitudes shown shall be replaced by implementation-defined magnitudes with the same sign." #define UINT_MAX 65535 Key here is implementation-defined , with a minimum of 65535.
The next question: Why? (To clarify: I mean, "why do you care what the bits are set to".)
I'm not sure what you mean. If you meant "why worry about bits, you should be dealing with values", then there are plenty of cases where that isn't true. Lots of programs (e.g. embedded programs) have to deal with actual bits, not with the values themselves. Just as an example, flags. (I don't know if this is what you meant, so apologies if I misunderstood your question.)
This seems like too much abstraction for a C programmer, I know, but there is already precedent. int and int * are not the same type; if you use one as the other the compiler will tell you not to, even though they are the exact same bits in memory.
Earlier quoted context omitted.
I'm not sure what you mean. If you meant "why worry about bits, you should be dealing with values", then there are plenty of cases where that isn't true. Lots of programs (e.g. embedded programs) have to deal with actual bits, not with the values themselves. Just as an example, flags. (I don't know if this is what you meant, so apologies if I misunderstood your question.)
So why not have a type that's "bitfield64" or something, and not worry how the machine represents your integer. This seems like too much abstraction for a C programmer, I know, but there is already precedent. int and int * are not the same type; if you use one as the other the compiler will tell you not to, even though they are the exact same bits in memory.
We made sure that each one of these had the correct bit amounts in the mapping, and that way, you always knew exactly how many bits you were working with, which is important in embedded systems (where memory is important, and where you usually have structures which directly map to e.g. ip headers, so you need exact sizes).
By the way, even the words byte/word/dword might cause confusion, cause none of them are well defined either. Some architectures assign a word 16 bits, some 32 bits. And believe it or not, some architectures even assign bytes a number of bits different than 8! The "officially correct" term, I believe, is Octet, which is defined as 8 bits. Of course, we just decided internally what we meant by byte, word and dword, and that worked fine.