Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > conversion

Reply
Thread Tools

conversion

 
 
Richard Heathfield
Guest
Posts: n/a
 
      11-16-2007
Roman Mashak said:

<snip>

> Compiling it with borland builder results with warning on
> "pIRV->Val&=~Mask" line: "conversion may loose significant digits". Both
> operands are (pIRV->Val and Mask) of the same type (UCHAR, which is
> 'unsigned char'). What's wrong with this snippet?


Nothing. The "significant digits" that you might lose are insignificant,
since they are a side-effect of promotion with which you need not concern
yourself for the purposes of this line of code.

Let's assume 8-bit bytes, 2-byte ints (because it's less to type).

We'll assume pIRV->Val has the value 00111101, and Mask has the value
10101010.

If you thought ~Mask was 01010101, you'd be forgivably wrong. It's actually
1111111101010101 (on the system we're assuming). When you & this with
00111101 (or rather, 0000000000111101) you get 0000000000010101, and you
then store this in an unsigned char, getting 00010101, which is precisely
what you want.

If your system has bigger bytes, bigger ints, or both, then you just get
more leading 0s to ignore. No big deal.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      11-16-2007
Roman Mashak said:

<snip>

> RH> If you thought ~Mask was 01010101, you'd be forgivably wrong. It's
> RH> actually
> RH> 1111111101010101 (on the system we're assuming). When you & this
> with
>
> Does it have something to do with alignment? Why is byte converted to
> int?


On (possibly spurious) efficiency grounds.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      11-16-2007
Roman Mashak said:

> Hello, Richard!
> You wrote on Fri, 16 Nov 2007 09:27:51 +0000:
>
> RH>>> If you thought ~Mask was 01010101, you'd be forgivably wrong. It's
> RH>>> actually
> RH>>> 1111111101010101 (on the system we're assuming). When you & this
> ??>> with
> ??>>
> ??>> Does it have something to do with alignment? Why is byte converted
> to ??>> int?
>
> RH> On (possibly spurious) efficiency grounds.
> Are these grounds declared by ANSI standard,


Not in so many words, no, but the Standard does say that "A ``plain'' int
object has the natural size suggested by the architecture of the execution
environment". The values of objects of smaller size very often (always?)
get promoted to this "natural size" during calculations.

> is this conversion required
> to be done by every implementation?


Yes. Look up "integer promotion" and "the usual arithmetic conversions".

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      11-16-2007
Richard Heathfield wrote:
> Roman Mashak said:
>
> <snip>
>
>> RH> If you thought ~Mask was 01010101, you'd be forgivably wrong. It's
>> RH> actually
>> RH> 1111111101010101 (on the system we're assuming). When you & this
>> with
>>
>> Does it have something to do with alignment? Why is byte converted to
>> int?

>
> On (possibly spurious) efficiency grounds.


... for very small values of "possibly." Lots of machines
that implement C lack the ability to perform arithmetic on
"narrow" operands like `short x' or `char y' or `int z : 3'.
Usually, a machine that can't perform three-bit arithmetic
will instead load the narrow quantity into a wider "register"
or something of the kind, use its native wide arithmetic to
operate on the widened operand, and then store part of the
wide result into a narrow destination. C's "promotions" are
a recognition of this common implementation practice.

(It's been almost forty years since I last encountered
a machine that could do "native" arithmetic on a three-bit
integer.)

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      11-16-2007
Eric Sosman said:
> Richard Heathfield wrote:
>> Roman Mashak said:
>>
>>> Why is byte converted to int?

>>
>> On (possibly spurious) efficiency grounds.

>
> ... for very small values of "possibly."


32-bit char, anyone? Lots of those around in the embedded world. Promotion
to int on efficiency grounds is 100% pointless on CSILP32 systems.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      11-16-2007
Roman Mashak wrote:
>
> typedef struct {
> UCHAR Num;
> UCHAR Mask;
> UCHAR Val;
> } IRVType, *PIRVType;
> ...
> bool SetIRVBit(PIRVType pIRV, UCHAR Num, UCHAR Mask, UCHAR Val)
> {
> while (pIRV->Num || pIRV->Mask || pIRV->Val) {
> if (pIRV->Num!=Num) {
> pIRV++;
> continue;
> }
> pIRV->Mask|=Mask;
> pIRV->Val&=~Mask;
> pIRV->Val|=Val;
> return TRUE;
> }
> return FALSE;
> }
>
> Compiling it with borland builder results with warning on "pIRV->Val&=~Mask"
> line: "conversion may loose significant digits". Both operands are
> (pIRV->Val and Mask) of the same type (UCHAR, which is 'unsigned char').
> What's wrong with this snippet?


No they're not. One is of the type ~Mask, which is an int.

In addition, I believe your cavalier action of incrementing the
pointer pIRV should be flagged as an error. Pointers are not
integers.

Thirdly, you are using the type 'bool'. This implies the use of
C99, and #include <stdbool.h>. This also defines the standard
values true and false (lower case).

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Roman Mashak
Guest
Posts: n/a
 
      11-17-2007
Hello,

typedef struct {
UCHAR Num;
UCHAR Mask;
UCHAR Val;
} IRVType, *PIRVType;
....
bool SetIRVBit(PIRVType pIRV, UCHAR Num, UCHAR Mask, UCHAR Val)
{
while (pIRV->Num || pIRV->Mask || pIRV->Val)
{
if (pIRV->Num!=Num)
{
pIRV++;
continue;
}

pIRV->Mask|=Mask;
pIRV->Val&=~Mask;
pIRV->Val|=Val;
return TRUE;
}
return FALSE;
}

Compiling it with borland builder results with warning on "pIRV->Val&=~Mask"
line: "conversion may loose significant digits". Both operands are
(pIRV->Val and Mask) of the same type (UCHAR, which is 'unsigned char').
What's wrong with this snippet?

Thanks.

With best regards, Roman Mashak. E-mail: (E-Mail Removed)


 
Reply With Quote
 
Roman Mashak
Guest
Posts: n/a
 
      11-17-2007
Hello, Richard!
You wrote on Fri, 16 Nov 2007 08:12:11 +0000:

[skip]
RH> Let's assume 8-bit bytes, 2-byte ints (because it's less to type).

RH> We'll assume pIRV->Val has the value 00111101, and Mask has the value
RH> 10101010.

RH> If you thought ~Mask was 01010101, you'd be forgivably wrong. It's
RH> actually
RH> 1111111101010101 (on the system we're assuming). When you & this with

Does it have something to do with alignment? Why is byte converted to int?

RH> 00111101 (or rather, 0000000000111101) you get 0000000000010101, and
RH> you then store this in an unsigned char, getting 00010101, which is
RH> precisely what you want.

RH> If your system has bigger bytes, bigger ints, or both, then you just
RH> get more leading 0s to ignore. No big deal.

With best regards, Roman Mashak. E-mail: (E-Mail Removed)


 
Reply With Quote
 
Roman Mashak
Guest
Posts: n/a
 
      11-17-2007
Hello, Richard!
You wrote on Fri, 16 Nov 2007 09:27:51 +0000:

RH>>> If you thought ~Mask was 01010101, you'd be forgivably wrong. It's
RH>>> actually
RH>>> 1111111101010101 (on the system we're assuming). When you & this
??>> with
??>>
??>> Does it have something to do with alignment? Why is byte converted to
??>> int?

RH> On (possibly spurious) efficiency grounds.
Are these grounds declared by ANSI standard, is this conversion required to
be done by every implementation? Could you tell me more about it or provide
some links/hints.
Thanks.

With best regards, Roman Mashak. E-mail: (E-Mail Removed)


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-18-2007
CBFalconer wrote:
> Roman Mashak wrote:
>> typedef struct {
>> UCHAR Num;
>> UCHAR Mask;
>> UCHAR Val;
>> } IRVType, *PIRVType;
>> ...
>> bool SetIRVBit(PIRVType pIRV, UCHAR Num, UCHAR Mask, UCHAR Val)
>> {
>> while (pIRV->Num || pIRV->Mask || pIRV->Val) {
>> if (pIRV->Num!=Num) {
>> pIRV++;
>> continue;
>> }
>> pIRV->Mask|=Mask;
>> pIRV->Val&=~Mask;
>> pIRV->Val|=Val;
>> return TRUE;
>> }
>> return FALSE;
>> }
>>
>> Compiling it with borland builder results with warning on "pIRV->Val&=~Mask"
>> line: "conversion may loose significant digits". Both operands are
>> (pIRV->Val and Mask) of the same type (UCHAR, which is 'unsigned char').
>> What's wrong with this snippet?

>
> No they're not. One is of the type ~Mask, which is an int.


You mean it's of the type *of* ~Mask.

> In addition, I believe your cavalier action of incrementing the
> pointer pIRV should be flagged as an error. Pointers are not
> integers.


No, they certainly aren't, but incrementing a pointer is well defined.

> Thirdly, you are using the type 'bool'. This implies the use of
> C99, and #include <stdbool.h>. This also defines the standard
> values true and false (lower case).


No, it doesn't imply the use of C99. "bool" is a valid identifier in
C90. For that matter, "bool" is a valid identifier in C99, particularly
if there's no "#include <stdbool.h>". Probably the type "bool" and
the identifiers (macros?) "FALSE" and "TRUE" are defined elsewhere. (It
would have been nice to see those declarations, and the declaration of
UCHAR.)

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
PSD to XHTML Conversion Services and PSD to HTML CSS ConversionServices, PSD to Joomla, Drupal, Wordpress Conversion xhtml champs Python 0 06-21-2011 11:59 AM
PSD to XHTML Conversion Services and PSD to HTML CSS ConversionServices, PSD to Joomla, Drupal, Wordpress Conversion PSD to XHTML Conversion Services and PSD to HTML CSS Conversion Services, PSD to Joomla, Drupal, Wor VHDL 0 04-25-2011 06:43 AM
conversion operator and conversion ctor subramanian100in@yahoo.com, India C++ 2 09-15-2009 12:46 PM
Date conversion problem with OE importing saroxonline76@vodafone.it Firefox 0 07-12-2005 07:38 PM
Framework 1.0 to 1.1 conversion Luc Bisson ASP .Net 2 11-19-2003 02:40 AM



Advertisments