Velocity Reviews > types and conversions

# types and conversions

Keith Thompson
Guest
Posts: n/a

 06-01-2010
[...]
> Okay, to my defense, I wasn't aware that the result of (0u - 1u) was
> "reduced modulo the number that is one greater than the largest value
> that can be represented by the resulting type". This probably due to
> the fact that I don't have the C99 standard, and hence, haven't read
> it.

The latest post-C99 draft is freely available at
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Richard Bos
Guest
Posts: n/a

 06-01-2010

> On May 31, 2:05=A0pm, Keith Thompson <(E-Mail Removed)> wrote:

> > So now we have (0u - 1u). =A0The *mathematical* result of this subtraction
> > is -1, but -1 cannot be represented directly as an unsigned int value,
> > so the result is "reduced modulo the number that is one greater than the
> > largest value that can be represented by the resulting type" (C99
> > 6.2.5p9).

> Okay, to my defense, I wasn't aware that the result of (0u - 1u) was
> "reduced modulo the number that is one greater than the largest value
> that can be represented by the resulting type". This probably due to
> the fact that I don't have the C99 standard, and hence, haven't read
> it.

It's also in C90, as well as (logically) in K&R 2.

Richard

Francis Moreau
Guest
Posts: n/a

 06-01-2010
On May 31, 1:53*pm, Eric Sosman <(E-Mail Removed)> wrote:
> On 5/31/2010 12:37 AM, Mark wrote:
>
>
>
>
>
> > I'm somewaht confused with what type to choose and possible conversion
> > it may have to undergo. Let me explain with a real example:

>
> > ...

>
> > #define REG_PORT 0x50
> > /* ports enumerate from 1 to 25 */

>
> > {
> > int rv;
> > uint16_t val;

>
> > addr = REG_PORT + ((port - 1) / 3);
> > ....
> > return rv;
> > }

>
> > As far as I know, only in the absence of a prototype, function arguments
> > unfergo default promotions. We have prototypes, so no
> > promotion/conversion apply to arguments, am I tight?

>
> * * *Based on the loose wording and spelling errors, I'd say it's
> at least plausible that you might be tight. *
>
> * * *As for the rest,
>
> * * *- The default argument promotions apply when there is no prototype,
> * * * *and to arguments in the "..." part of a variable-argument function
> * * * *(which must have a prototype).
>
> * * *- An argument matching a prototyped parameter does not undergo the
> * * * *default argument promotions, but it *is* converted (if necessary)
> * * * *to the type specified by the prototype.
>
> * * *- In your example, one such non-trivial conversion does in fact
> * * * *occur: The second argument expression in the call to read_reg()
> * * * *is of type `unsigned short', and this expression is converted
> * * * *to `unsigned int' as directed by the prototype.
>

Sorry but I don't understand the last part: the prototype of
'read_reg()' specifies that the type of the second parameter is
'unsigned short'. So why is the second argument converted to 'unsigned
int' ?

Thanks

Ian Collins
Guest
Posts: n/a

 06-01-2010
On 06/ 2/10 10:25 AM, Francis Moreau wrote:
> On May 31, 1:53 pm, Eric Sosman<(E-Mail Removed)> wrote:
>> On 5/31/2010 12:37 AM, Mark wrote:
>>
>>> I'm somewaht confused with what type to choose and possible conversion
>>> it may have to undergo. Let me explain with a real example:

>>
>>> ...

>>
>>> #define REG_PORT 0x50
>>> /* ports enumerate from 1 to 25 */

>>
>>> {
>>> int rv;
>>> uint16_t val;

>>
>>> addr = REG_PORT + ((port - 1) / 3);
>>> ....
>>> return rv;
>>> }

>>
>>> As far as I know, only in the absence of a prototype, function arguments
>>> unfergo default promotions. We have prototypes, so no
>>> promotion/conversion apply to arguments, am I tight?

>>
>> Based on the loose wording and spelling errors, I'd say it's
>> at least plausible that you might be tight.
>>
>> As for the rest,
>>
>> - The default argument promotions apply when there is no prototype,
>> and to arguments in the "..." part of a variable-argument function
>> (which must have a prototype).
>>
>> - An argument matching a prototyped parameter does not undergo the
>> default argument promotions, but it *is* converted (if necessary)
>> to the type specified by the prototype.
>>
>> - In your example, one such non-trivial conversion does in fact
>> occur: The second argument expression in the call to read_reg()
>> is of type `unsigned short', and this expression is converted
>> to `unsigned int' as directed by the prototype.
>>

>
> Sorry but I don't understand the last part: the prototype of
> 'read_reg()' specifies that the type of the second parameter is
> 'unsigned short'. So why is the second argument converted to 'unsigned
> int' ?

Where the prototype was:

Hence addr is promoted from "unsigned short" to "unsigned int".

--
Ian Collins

Francis Moreau
Guest
Posts: n/a

 06-02-2010
On Jun 2, 12:39*am, Ian Collins <(E-Mail Removed)> wrote:
> On 06/ 2/10 10:25 AM, Francis Moreau wrote:
>
>
>
>
>
> > On May 31, 1:53 pm, Eric Sosman<(E-Mail Removed)> *wrote:
> >> On 5/31/2010 12:37 AM, Mark wrote:

>
> >>> I'm somewaht confused with what type to choose and possible conversion
> >>> it may have to undergo. Let me explain with a real example:

>
> >>> ...

>
> >>> #define REG_PORT 0x50
> >>> /* ports enumerate from 1 to 25 */

>
> >>> {
> >>> int rv;
> >>> uint16_t val;

>
> >>> addr = REG_PORT + ((port - 1) / 3);
> >>> ....
> >>> return rv;
> >>> }

>
> >>> As far as I know, only in the absence of a prototype, function arguments
> >>> unfergo default promotions. We have prototypes, so no
> >>> promotion/conversion apply to arguments, am I tight?

>
> >> * * * Based on the loose wording and spelling errors, I'd say it's
> >> at least plausible that you might be tight. *

>
> >> * * * As for the rest,

>
> >> * * * - The default argument promotions apply when there is no prototype,
> >> * * * * and to arguments in the "..." part of a variable-argument function
> >> * * * * (which must have a prototype).

>
> >> * * * - An argument matching a prototyped parameter does not undergo the
> >> * * * * default argument promotions, but it *is* converted (if necessary)
> >> * * * * to the type specified by the prototype.

>
> >> * * * - In your example, one such non-trivial conversion does in fact
> >> * * * * occur: The second argument expression in the call to read_reg()
> >> * * * * is of type `unsigned short', and this expression is converted
> >> * * * * to `unsigned int' as directed by the prototype.

>
> > Sorry but I don't understand the last part: the prototype of
> > 'read_reg()' specifies that the type of the second parameter is
> > 'unsigned short'. So why is the second argument converted to 'unsigned
> > int' ?

>
>
>
>
> Where the prototype was:
>
>
> Hence addr is promoted from "unsigned short" to "unsigned int".

Damn I mis read the prototypes.

Sorry for the noise.