faqcatee08.html

this is a mirrored site c-faq. thought might need offline

<p>References:

K&amp;R1 Sec. 2.8 p. 43
<br>
K&amp;R2 Sec. 2.8 p. 47
<br>
ISO Sec. 6.3.2.4, Sec. 6.3.3.1
<br>
H&amp;S Sec. 7.4.4 pp. 192-3, Sec. 7.5.8 pp. 199-200
<hr><hr><hr>
<a name="transitivity">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../expr/transitivity.html"><!-- qtag -->Question 3.13</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I need to check whether one number lies between two others.
Why doesn't
<pre>
if(a &lt; b &lt; c)</pre>

work?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
The relational operators,
such as <TT>&lt;</TT>,

are all binary;
they compare two operands and return
a true or false
(1 or 0)
result.
Therefore, the expression
<TT>a &lt; b &lt; c</TT> compares <TT>a</TT> to <TT>b</TT>,
and then checks whether the resulting 1 or 0 is less than <TT>c</TT>.
(To see it more clearly,
imagine that it had been written as
<TT>(a &lt; b) &lt; c</TT>,
because that's how the compiler interprets it.)
To check whether one number lies between two others,
use code like this:
<pre>
	if(a &lt; b &amp;&amp; b &lt; c)
</pre>
</p>





<p>References:

K&amp;R1 Sec. 2.6 p. 38
<br>
K&amp;R2 Sec. 2.6 pp. 41-2
<br>
ISO Sec. 6.3.8, Sec. 6.3.9
<br>
H&amp;S Secs. 7.6.4,7.6.5 pp. 207-210
<hr><hr><hr>
<a name="intoverflow1">
<hr><hr><hr>
<a name="intovf3">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../expr/intovf3.html"><!-- qtag -->Question 3.14b</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
How can I ensure that integer arithmetic doesn't overflow?
</p>
<p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
See question <a href="faqcat38c2.html?sec=misc#intovf">20.6b</a>.
<hr><hr><hr>
<a name="truncation1">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../expr/truncation1.html"><!-- qtag -->Question 3.15</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
Why does the code
<pre>
double degC, degF;
degC = 5 / 9 * (degF - 32);</pre>

keep giving me 0?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
If both operands of a binary operator are integers,
C performs an integer operation,
regardless of the type of the rest of the expression.
In this case,
the integer operation is
truncating division,
yielding 5 / 9 = 0.
(Note,
though,
that the problem of having subexpressions evaluated in an
unexpected type
is not restricted to division,
nor for that matter to type <TT>int</TT>.)
If you cast one of the operands to <TT>float</TT> or <TT>double</TT>,
or use a floating-point constant,
i.e.
<pre>
	degC = (double)5 / 9 * (degF - 32);
or
	degC = 5.0 / 9 * (degF - 32);
</pre>

it will
work as you expect.
Note that the cast must be on one of the operands;
casting the result
(as in <TT>(double)(5&nbsp;/&nbsp;9)&nbsp;* (degF&nbsp;-&nbsp;32)</TT>)
would not help.
</p><p>See also question <a href="faqcatee08.html?sec=expr#intoverflow1">3.14</a>.
</p>





<p>References:

K&amp;R1 Sec. 1.2 p. 10, Sec. 2.7 p. 41
<br>
K&amp;R2 Sec. 1.2 p. 10, Sec. 2.7 p. 44
<br>
ISO Sec. 6.2.1.5
<br>
H&amp;S Sec. 6.3.4 p. 176
<hr><hr><hr>
<a name="qcolonlhs">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../expr/qcolonlhs.html"><!-- qtag -->Question 3.16</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I have a complicated expression which
I have
to assign
to one 
of two variables,
depending on a condition.
Can I use code like this?
<pre>
	((condition) ? a : b) = complicated_expression;
</pre>
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
No.

The <TT>?:</TT> operator,
like most operators,
yields a value,
and you can't assign to a value.
(In other words, <TT>?:</TT> does not yield an <a href="../../sx1/index.html#lvalue"><dfn>lvalue</dfn></a>.)

If you really want to,
you can try something like
<pre>
	*((condition) ? &amp;a : &amp;b) = complicated_expression;
</pre>
although this is admittedly not as pretty.
</p>


<p>References:

ISO Sec. 6.3.15
<br>
H&amp;S Sec. 7.1 pp. 179-180
<hr><hr><hr>
<a name="ternprec">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../expr/ternprec.html"><!-- qtag -->Question 3.17</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
I have
some code
containing expressions
like
<pre>
a ? b = c : d</pre>

and some compilers are accepting it but some are not.
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
In the original definition of
the language,
<TT>=</TT> was of lower precedence
than <TT>?:</TT>,
so early compilers tended to trip up on an expression like
the one above,
attempting to parse it as
if it had been written
<pre>
	(a ? b) = (c : d)
</pre>
Since it has no other sensible meaning, however,
later compilers have allowed
the expression,
and interpret it
as if
an inner set of
parentheses were implied:
<pre>
	a ? (b = c) : d
</pre>
Here,
the left-hand operand of the <TT>=</TT> is simply <TT>b</TT>,
not the invalid <TT>a&nbsp;?&nbsp;b</TT>.
In fact,
the grammar specified in the ANSI/ISO C Standard
effectively requires this interpretation.
(The grammar in the Standard
is not precedence-based,
and says that any expression may appear between
the <TT>?</TT> and <TT>:</TT> symbols.)
</p><p>An expression like the one in the question is

perfectly acceptable to an ANSI compiler,
but if you ever have to compile it under an older compiler,
you can always add the explicit, inner parentheses.

</p>


<p>References:

K&amp;R1 Sec. 2.12 p. 49
<br>
ISO Sec. 6.3.15
<br>
Rationale Sec. 3.3.15
<hr><hr><hr>
<a name="unswarn">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../expr/unswarn.html"><!-- qtag -->Question 3.18</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What does the warning
``semantics of `<TT>&gt;</TT>' change in ANSI C''
mean?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
This message represents an attempt
by certain
(perhaps overzealous)
compilers
to warn you
that
some code
may perform differently under the ANSI C ``value preserving''
rules than under the older ``unsigned preserving'' rules.
</p><p>


The wording of this
message
is rather confusing because what has changed
is not really the semantics of the <TT>&gt;</TT> operator
itself
(in
fact,
almost any C operator can appear in the
message),
but
rather
the semantics
of the implicit conversions

which always occur when
two dissimilar types meet across a binary operator,
or when a narrow integral type must be promoted.
</p><p>(If you didn't think you were using any unsigned values
in your expression,
the
most likely
culprit is <TT>strlen</TT>.
In Standard C,
<TT>strlen</TT> returns
<TT>size_t</TT>,
which is an unsigned type.)

</p><p>See question <a href="faqcatee08.html?sec=expr#preservingrules">3.19</a>.
<hr><hr><hr>
<a name="preservingrules">
<h1>
comp.lang.c FAQ list
<font color=blue>&middot;</font>
<a href="../../expr/preservingrules.html"><!-- qtag -->Question 3.19</a>
</h1>
<p>
<font face=Helvetica size=8 color=blue><b>Q:</b></font>
What's the difference between the ``unsigned preserving''
and ``value preserving'' rules?
</p><p><hr>
<p>
<font face=Helvetica size=8 color=blue><b>A:</b></font>
These rules concern the behavior
when
an unsigned type must be promoted to a ``larger'' type.
Should it be promoted to a larger signed or unsigned type?
(To foreshadow the answer,
it may depend
on whether the larger type is truly larger.)
</p><p>Under the unsigned preserving
(also called ``sign preserving'')
rules,
the promoted type
is always unsigned.
This rule has the virtue of simplicity,
but it
can lead to surprises
(see the first example below).
</p><p>Under the value preserving rules,
the conversion depends on the actual sizes of the
original and promoted
types.
If the promoted type is truly larger--which
means that it can represent all the values of the
original, unsigned
type as signed values--then the promoted type
is signed.
If the two types are actually the same size,
then the promoted type is unsigned
(as for the unsigned preserving rules).
</p><p>Since the <em>actual</em> sizes of the types are used
in making the determination,
the results
will vary from machine to machine.
On some machines,
<TT>short&nbsp;int</TT> is smaller than <TT>int</TT>,
but on some machines, they're the same size.
On some machines,
<TT>int</TT> is smaller than <TT>long&nbsp;int</TT>,
but on some machines, they're the same size.
</p><p>



In practice, the difference between the unsigned and
value preserving rules matters most often when one operand of
a binary
operator is (or promotes to) <TT>int</TT>
and the other one might,
depending on the promotion rules, be either <TT>int</TT> or
<TT>unsigned int</TT>.
If one operand is <TT>unsigned int</TT>, the other
will be converted to that type--almost certainly causing
an undesired result if its value was negative
(again, see the first example below).
When the ANSI
C Standard was established, the value preserving rules were
chosen, to reduce the number of cases where
these surprising results occur.
(On the other hand,
the value preserving rules also reduce
the number of <em>predictable</em> cases,
because portable programs cannot depend on a machine's type sizes
and hence cannot know which way the value preserving rules will fall.)
</p><p>Here is a contrived example
showing the sort of surprise
that can

occur under the unsigned preserving rules:
<pre>
	unsigned short us = 10;
	int i = -5;
	if(i &gt; us)
		printf("whoops!\n");
</pre>
The important issue is how
the expression <TT>i&nbsp;&gt;&nbsp;us</TT> is evaluated.
Under the unsigned preserving rules
(and under the value preserving rules on a machine where 
<TT>short</TT> integers and plain integers are the same size),
<TT>us</TT> is promoted to 
<TT>unsigned&nbsp;int</TT>.
The usual integral conversions say that when types
<TT>unsigned&nbsp;int</TT> and <TT>int</TT> meet across a binary operator,
both operands are converted to unsigned,
so <TT>i</TT> is converted to <TT>unsigned&nbsp;int</TT>, as well.
The old value of <TT>i</TT>, -5,
is converted to some 
large unsigned value (65,531 on a 16-bit machine).
This converted value is greater than 10,
so the code prints ``whoops!''
</p><p>Under the value preserving rules,
on a machine where
plain integers are larger than <TT>short</TT> integers,
<TT>us</TT> is converted to a plain <TT>int</TT>
(and retains its value, 10),
and <TT>i</TT> remains a plain <TT>int</TT>.
The
expression is not true,
and the code prints nothing.
(To see why the values can be preserved only when the signed type is larger,
remember that a value like 40,000 can be represented
as an unsigned 16-bit integer but not as a signed one.)
</p><p>Unfortunately, the value preserving rules
do not prevent all surprises.
The example just presented still prints ``whoops''
on a machine where short and plain integers are the same size.
The
value preserving rules
may also inject a few surprises of their
own--consider
the code:
<pre>
	unsigned char uc = 0x80;
	unsigned long ul = 0;
	ul |= uc &lt;&lt; 8;
	printf("0x%lx\n", ul);
</pre>
Before being left-shifted, <TT>uc</TT> is promoted.
Under the unsigned preserving rules,
it is promoted to an <TT>unsigned&nbsp;int</TT>,
and the code goes on to print <TT>0x8000</TT>,
as expected.
Under the value preserving rules, however,
<TT>uc</TT> is promoted to a <em>signed</em> int
(as long as <TT>int</TT>'s are larger than <TT>char</TT>'s,
which is usually the case).
The intermediate result <TT>uc&nbsp;&lt;&lt;&nbsp;8</TT>
goes on to
meet
<TT>ul</TT>,
which is <TT>unsigned&nbsp;long</TT>.
The signed, intermediate result must therefore be promoted as well,
and if <TT>int</TT> is smaller than <TT>long</TT>,
the intermediate result
is sign-extended,
becoming
<TT>0xffff8000</TT> on a machine with 32-bit <TT>long</TT>s.
On such a machine,
the code prints <TT>0xffff8000</TT>,
which is probably not what was expected.
(On machines where <TT>int</TT> and <TT>long</TT> are the same size,
the code
prints <TT>0x8000</TT>
under either set of rules.)
</p><p>To avoid surprises
(under either set of rules,
or due to an unexpected change of rules),
it's best to avoid mixing signed and unsigned types in the same 
expression,
although as the second example shows,
this rule is not always sufficient.
You can
always
use explicit casts
to indicate,
unambiguously,
exactly
where and how you want conversions performed;
see questions
<a href="faqcat1d60.html?sec=stdio#extconform">12.42</a>
and
<a href="faqcat5e04.html?sec=strangeprob#ptralign">16.7</a>
for examples.
(Some compilers attempt to warn you when they detect ambiguous 
cases
or expressions which would have behaved differently under the 
unsigned preserving rules,
although sometimes these warnings fire too often;
see also question <a href="faqcatee08.html?sec=expr#unswarn">3.18</a>.)
</p>








<p>References:

K&amp;R2 Sec. 2.7 p. 44, Sec. A6.5 p. 198, Appendix C p. 260
<br>
ISO Sec. 6.2.1.1, Sec. 6.2.1.2, Sec. 6.2.1.5
<br>
Rationale Sec. 3.2.1.1
<br>
H&amp;S Secs. 6.3.3,6.3.4 pp. 174-177
<hr><hr><hr>
<hr>
<p>
Read sequentially:
<a href="faqcat6b6b.html?sec=struct" rev=precedes>prev</a>
<a href="faqcatabdc.html?sec=ptrs" rel=precedes>next</a>
<a href="faqcat.html" rev=subdocument>up</a>
</p>
<hr>
<p>
<br><!-- lastfooter -->
<a href="../../about.html">about this FAQ list</a>
&nbsp;
<a href="../../eskimo.html">about eskimo</a>
&nbsp;
<a href="../../search.html">search</a>
&nbsp;
<a href="../../feedback.html">feedback</a>
&nbsp;
<a href="../../expr/copyright.html">copyright</a>
<p>
Hosted by
<a href="http://www.eskimo.com/"><img src="../../../www.eskimo.com/img/link/eskitiny.gif" alt="Eskimo North"></a>
</body>

<!-- Mirrored from c-faq.com/~scs/cgi-bin/faqcat.cgi?sec=expr by HTTrack Website Copier/3.x [XR&CO'2008], Sat, 14 Mar 2009 07:57:39 GMT -->
</html>