3 ms·

Wouldn't that put it in the bss section and therefore not initialize it (but most OS's will probably zero out the page for security reasons)? Ether way, as it'

by a1k0n 15y ago

Wouldn't that put it in the bss section and therefore not initialize it (but most OS's will probably zero out the page for security reasons)? Ether way, as it's a 1-bit field, the value can only be 0 or 1 and is always > -3.

prodigal_erik 15y ago
I think the problem is that -3 < 1 but -3 > 1U because the -3 is "promoted" (quietly corrupted) to UINT_MAX - 2 (edit: C99 guarantees this value). So the question is whether a small unsigned bitfield is handled like a signed int (which can represent all its possible values) or an unsigned int (which is more like what you asked for). It's just astounding how many developer-years have been wasted by the industry's insistence on producing and accepting wrong answers when commodity hardware has been maintaining under/overflow flags for literally my entire career.
- caf 15y ago
  -3 > 1U is guaranteed to be true. Conversion of an out-of-range value to an unsigned type is well-defined in C: it is taken modulo one greater than the maximum value representable in the target type. (unsigned)-3 must always be equal to UINT_MAX - 2, there is no choice for the implementation here. Conversion of out-of-range values to signed types is, however, implementation-defined (and also allows an implementation-defined signal to be raised, which in practice makes it something to avoid in correct programs).
  - prodigal_erik 15y ago
    Thank you, I wasn't aware that C99 now mandates the twos-complement result; I think it had been implementation-defined in C89 (which is all I ever used seriously). http://stackoverflow.com/questions/50605/signed-to-unsigned-conversion-in-c-is-it-always-safe http://stackoverflow.com/questions/50605/signed-to-unsigned-...
    - caf 15y ago
      C89 has this language in §3.1.2.5 Types: 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 unsigned integer type.
caf 15y ago
It is a requirement of the C standard that objects with static storage duration are initialised to a "zero of the appropriate type" (which eg. means NULL for pointers). In most implementations this can take advantange of the BSS section (which is why the requirement came about in the first place), but it's required to work even on eg. MS-DOS. For the second part of your comment, comparisons are always done between the same type. In this case, either the -3 is promoted to unsigned (which gives the result UINT_MAX - 2, a large positive number) or the bitfield is promoted to int. It is the rules for this type promotion that is the heart of the problem.

by a1k0n 15y ago

prodigal_erik 15y ago

I think the problem is that -3 < 1 but -3 > 1U because the -3 is "promoted" (quietly corrupted) to UINT_MAX - 2 (edit: C99 guarantees this value). So the question is whether a small unsigned bitfield is handled like a signed int (which can represent all its possible values) or an unsigned int (which is more like what you asked for). It's just astounding how many developer-years have been wasted by the industry's insistence on producing and accepting wrong answers when commodity hardware has been maintaining under/overflow flags for literally my entire career.

caf 15y ago
-3 > 1U is guaranteed to be true. Conversion of an out-of-range value to an unsigned type is well-defined in C: it is taken modulo one greater than the maximum value representable in the target type. (unsigned)-3 must always be equal to UINT_MAX - 2, there is no choice for the implementation here. Conversion of out-of-range values to signed types is, however, implementation-defined (and also allows an implementation-defined signal to be raised, which in practice makes it something to avoid in correct programs).
- prodigal_erik 15y ago
  Thank you, I wasn't aware that C99 now mandates the twos-complement result; I think it had been implementation-defined in C89 (which is all I ever used seriously). http://stackoverflow.com/questions/50605/signed-to-unsigned-conversion-in-c-is-it-always-safe http://stackoverflow.com/questions/50605/signed-to-unsigned-...
  - caf 15y ago
    C89 has this language in §3.1.2.5 Types: 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 unsigned integer type.

caf 15y ago

It is a requirement of the C standard that objects with static storage duration are initialised to a "zero of the appropriate type" (which eg. means NULL for pointers). In most implementations this can take advantange of the BSS section (which is why the requirement came about in the first place), but it's required to work even on eg. MS-DOS. For the second part of your comment, comparisons are always done between the same type. In this case, either the -3 is promoted to unsigned (which gives the result UINT_MAX - 2, a large positive number) or the bitfield is promoted to int. It is the rules for this type promotion that is the heart of the problem.