Re: Type casting- a larger type to a smaller type

Discussion in 'C Programming' started by heyo, Apr 1, 2004.

  1. heyo

    heyo Guest

    Eric Sosman <> wrote in message news:<>...
    > Colin MacDougall wrote:
    > >
    > > Can anyone advise on the following please ?
    > > [...] The code seems to work
    > > fine, but I want to know if there is a 'proper' way to do
    > > this. I know that C supports type casting. [...]
    > >
    > > unsigned char eeprom_read(unsigned int address)
    > > {
    > > unsigned char h_add;
    > > h_add = address>>8; //get high part of address locator
    > > mem_write(h_add); //send the high part of the address
    > > mem_write(address & 0xff ); //send the low part of the address

    >
    > What you've shown seems fine. The only portability
    > threats are the // comments (the latest C99 Standard supports
    > them, but most compilers don't support C99 yet), and of course
    > whatever goes on inside mem_write().
    >
    > The variable `h_add' seems extraneous, and could probably
    > be done away with:
    >
    > mem_write (address >> 8);
    > mem_write (address & 0xff);
    >
    > are perfectly all right.


    The BC5 compiler would give you a warning: Conversion may loose
    significant digits. To turn them off (and to show everyone else
    you realy mean it) you'd have to include a type cast like:
    mem_write ((unsigned char)address >> 8);
    mem_write ((unsigned char)address & 0xff);
    A sightly more 'proper' way, though it doesn't change the generated
    code.
    (I suppose mem_write is declared as void mem_write(unsigned char xxx);)

    bye,
    heyo
     
    heyo, Apr 1, 2004
    #1
    1. Advertising

  2. heyo

    -berlin.de Guest

    heyo <> wrote:
    > Eric Sosman <> wrote in message news:<>...
    >> mem_write (address >> 8);
    >> mem_write (address & 0xff);
    >>
    >> are perfectly all right.


    > The BC5 compiler would give you a warning: Conversion may loose
    > significant digits. To turn them off (and to show everyone else
    > you realy mean it) you'd have to include a type cast like:
    > mem_write ((unsigned char)address >> 8);


    Make that

    mem_write ((unsigned char)(address >> 8));

    otherwise you first cast address to unsiged char before doing the
    shifting, thereby probably losing the upper bits you are actually
    interested in - the cast has a much higher precedence than the
    shift operator...
    Regards, Jens
    --
    \ Jens Thoms Toerring ___ -berlin.de
    \__________________________ http://www.toerring.de
     
    -berlin.de, Apr 1, 2004
    #2
    1. Advertising

  3. heyo

    Dan Pop Guest

    Re: Type casting- a larger type to a smaller type

    In <> (heyo) writes:

    >Eric Sosman <> wrote in message news:<>...
    >> Colin MacDougall wrote:
    >> >
    >> > Can anyone advise on the following please ?
    >> > [...] The code seems to work
    >> > fine, but I want to know if there is a 'proper' way to do
    >> > this. I know that C supports type casting. [...]
    >> >
    >> > unsigned char eeprom_read(unsigned int address)
    >> > {
    >> > unsigned char h_add;
    >> > h_add = address>>8; //get high part of address locator
    >> > mem_write(h_add); //send the high part of the address
    >> > mem_write(address & 0xff ); //send the low part of the address

    >>
    >> What you've shown seems fine. The only portability
    >> threats are the // comments (the latest C99 Standard supports
    >> them, but most compilers don't support C99 yet), and of course
    >> whatever goes on inside mem_write().
    >>
    >> The variable `h_add' seems extraneous, and could probably
    >> be done away with:
    >>
    >> mem_write (address >> 8);
    >> mem_write (address & 0xff);
    >>
    >> are perfectly all right.

    >
    >The BC5 compiler would give you a warning: Conversion may loose
    >significant digits. To turn them off (and to show everyone else
    >you realy mean it) you'd have to include a type cast like:
    > mem_write ((unsigned char)address >> 8);
    > mem_write ((unsigned char)address & 0xff);
    >A sightly more 'proper' way, though it doesn't change the generated
    >code.


    Throwing in bogus casts is NEVER proper. Any human can see that no
    significant digits may get lost (as long as addresses are 16-bit), so
    the casts are devoid of any value. Disable the bogus compiler diagnostic
    instead.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Apr 1, 2004
    #3
  4. heyo

    Dan Pop Guest

    Re: Type casting- a larger type to a smaller type

    In <c4h79i$2hku8k$> -berlin.de writes:

    >heyo <> wrote:
    >> Eric Sosman <> wrote in message news:<>...
    >>> mem_write (address >> 8);
    >>> mem_write (address & 0xff);
    >>>
    >>> are perfectly all right.

    >
    >> The BC5 compiler would give you a warning: Conversion may loose
    >> significant digits. To turn them off (and to show everyone else
    >> you realy mean it) you'd have to include a type cast like:
    >> mem_write ((unsigned char)address >> 8);

    >
    >Make that
    >
    > mem_write ((unsigned char)(address >> 8));
    >
    >otherwise you first cast address to unsiged char before doing the
    >shifting, thereby probably losing the upper bits you are actually
    >interested in - the cast has a much higher precedence than the
    >shift operator...


    A brilliant example of how a bogus compiler diagnostic can lead to
    broken (but not requiring a diagnostic) code.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Apr 1, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Peter Williams
    Replies:
    1
    Views:
    1,421
    Dylan Parry
    Jun 3, 2005
  2. pete
    Replies:
    4
    Views:
    809
    Dan Pop
    Apr 2, 2004
  3. korean_dave
    Replies:
    3
    Views:
    261
    Gary Herron
    Nov 14, 2008
  4. Matjaz Bezovnik
    Replies:
    4
    Views:
    319
    Robert Kern
    Aug 25, 2009
  5. Replies:
    5
    Views:
    149
    David Dorward
    Feb 9, 2005
Loading...

Share This Page