Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>Horrible Answers Galore</strong></p> <p><em>Ozgur Ozcitak</em></p> <blockquote> <p>When you cast from signed to unsigned (and vice versa) the internal representation of the number does not change. What changes is how the compiler interprets the sign bit.</p> </blockquote> <p>This is completely wrong.</p> <p><em>Mats Fredriksson</em></p> <blockquote> <p>When one unsigned and one signed variable are added (or any binary operation) both are implicitly converted to unsigned, which would in this case result in a huge result.</p> </blockquote> <p>This is also wrong. Unsigned ints may be promoted to ints should they have equal precision due to padding bits in the unsigned type.</p> <p><em>smh</em></p> <blockquote> <p>Your addition operation causes the int to be converted to an unsigned int.</p> </blockquote> <p>Wrong. Maybe it does and maybe it doesn't.</p> <blockquote> <p>Conversion from unsigned int to signed int is implementation dependent. (But it probably works the way you expect on most platforms these days.)</p> </blockquote> <p>Wrong. It is either undefined behavior if it causes overflow or the value is preserved.</p> <p><em>Anonymous</em></p> <blockquote> <p>The value of i is converted to unsigned int ...</p> </blockquote> <p>Wrong. Depends on the precision of an int relative to an unsigned int.</p> <p><em>Taylor Price</em></p> <blockquote> <p>As was previously answered, you can cast back and forth between signed and unsigned without a problem.</p> </blockquote> <p>Wrong. Trying to store a value outside the range of a signed integer results in undefined behavior.</p> <p><strong>Now I can finally answer the question.</strong></p> <p>Should the precision of int be equal to unsigned int, u will be promoted to a signed int and you will get the value -4444 from the expression (u+i). Now, should u and i have other values, you may get overflow and undefined behavior but with those exact numbers you will get -4444 <strong>[1]</strong>. This value will have type int. But you are trying to store that value into an unsigned int so that will then be cast to an unsigned int and the value that result will end up having would be (UINT_MAX+1) - 4444.</p> <p>Should the precision of unsigned int be greater than that of an int, the signed int will be promoted to an unsigned int yielding the value (UINT_MAX+1) - 5678 which will be added to the other unsigned int 1234. Should u and i have other values, which make the expression fall outside the range {0..UINT_MAX} the value (UINT_MAX+1) will either be added or subtracted until the result DOES fall inside the range {0..UINT_MAX) and no undefined behavior will occur.</p> <p><strong>What is precision?</strong></p> <p>Integers have padding bits, sign bits, and value bits. Unsigned integers do not have a sign bit obviously. Unsigned char is further guaranteed to not have padding bits. The number of values bits an integer has is how much precision it has.</p> <p>[Gotchas]</p> <p>The macro sizeof macro alone cannot be used to determine precision of an integer if padding bits are present. And the size of a byte does not have to be an octet (eight bits) as defined by C99.</p> <p><strong>[1]</strong> The overflow may occur at one of two points. Either before the addition (during promotion) - when you have an unsigned int which is too large to fit inside an int. The overflow may also occur after the addition even if the unsigned int was within the range of an int, after the addition the result may still overflow.</p> <hr> <p>On an unrelated note, I am a recent graduate student trying to find work ;)</p>
    singulars
    1. This table or related slice is empty.
    1. POSigned to unsigned conversion in C - is it always safe?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USElite Mx
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTDownMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTDownMod
    1. CO"Unsigned ints may be promoted to ints". Not true. No integer _promotion_ occurs as the types are already rank >= int. 6.3.1.1: "The rank of any unsigned integer type shall equal the rank of the corresponding signed integer type, if any." and 6.3.1.8: "Otherwise, if the operand that has unsigned integer type has rank greater **or equal** to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type." both guarantee that `int` is converted to `unsigned int` when the usual arithmetic conversions apply.
      singulars
      1. PO
      1. USCB Bailey
    2. CO6.3.1.8 Occurs only after integer promotion. Opening paragraph says "Otherwise, the integer promotions are performed on both operands. THEN the following rules are applied to the promoted operands". So go read the promotion rules 6.3.1.1 ... "An object or expression with an integer type whose integer conversion rank is less than or EQUAL to the rank of int and unsigned int" and "If an int can represent all values of the original type, the value is converted to an int".
      singulars
      1. PO
      1. USElite Mx
    3. CO6.3.1.1 Integer promotion used used to convert some integer types that aren't `int` or `unsigned int` to one of those types where something of type `unsigned int` or `int` is expected. The "or equal" was added in TC2 to allow enumerated types of conversion rank equal to `int` or `unsigned int` to be converted to one of those types. It was never intended that the promotion described would convert between `unsigned int` and `int`. The common type determination between `unsigned int` and `int` is still governed by 6.3.1.8, even post TC2.
      singulars
      1. PO
      1. USCB Bailey
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload