The strangest problem....

Discussion in 'C Programming' started by Jannick, Oct 9, 2003.

  1. Jannick

    Jannick Guest

    Hi I have:
    unsigned int myvalue=0;
    unsigned char mytest=0;

    mytest=0x34;
    myvalue = mytest<<24;

    Then myvalue gets the value 0x1A000000!!!!!
    How is this possible? Should'nt it be 0x34000000???

    Best Regards
    Jannick
     
    Jannick, Oct 9, 2003
    #1
    1. Advertising

  2. Jannick

    Allan Bruce Guest

    "Jannick" <> wrote in message
    news:bm3cko$qan$-c.dk...
    > Hi I have:
    > unsigned int myvalue=0;
    > unsigned char mytest=0;
    >
    > mytest=0x34;
    > myvalue = mytest<<24;
    >
    > Then myvalue gets the value 0x1A000000!!!!!
    > How is this possible? Should'nt it be 0x34000000???
    >
    > Best Regards
    > Jannick
    >
    >


    Are you sure, its not a typo in your program? 0x1A000000 is 0x34<<23
    Allan
     
    Allan Bruce, Oct 9, 2003
    #2
    1. Advertising

  3. "Jannick" <> schrieb im Newsbeitrag
    news:bm3cko$qan$-c.dk...
    > Hi I have:
    > unsigned int myvalue=0;
    > unsigned char mytest=0;
    >
    > mytest=0x34;
    > myvalue = mytest<<24;
    >
    > Then myvalue gets the value 0x1A000000!!!!!
    > How is this possible? Should'nt it be 0x34000000???


    Yes, it should (and is on my system, which of course doesn't proof
    anything).

    from the standard:
    "4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
    are filled with zeros. If E1 has an unsigned type, the value of the result
    is E1 x 2^E2, reduced modulo one more than the maximum value representable
    in the result type. If E1 has a signed type and nonnegative value, and E1 x
    2^E2 is representable in the result type, then that is the resulting value;
    otherwise, the behavior is undefined."

    The only explanation I have - besides a typo (23 instead of 24) in your
    actual code is something else in the code causing UB. I can't imagine, that
    your compiler is broken in _such_ a way.
    Can you post a minimum _compilable_ program which exhibits the error?

    Robert
     
    Robert Stankowic, Oct 9, 2003
    #3
  4. Jannick

    hongky Guest

    maybe your compiler os OS
    my VC+win32 is right,
    myvalue=0x34

    "Jannick" <> wrote in message
    news:bm3cko$qan$-c.dk...
    > Hi I have:
    > unsigned int myvalue=0;
    > unsigned char mytest=0;
    >
    > mytest=0x34;
    > myvalue = mytest<<24;
    >
    > Then myvalue gets the value 0x1A000000!!!!!
    > How is this possible? Should'nt it be 0x34000000???
    >
    > Best Regards
    > Jannick
    >
    >
     
    hongky, Oct 9, 2003
    #4
  5. Jannick

    Dan Pop Guest

    In <bm3cko$qan$-c.dk> "Jannick" <> writes:

    >unsigned int myvalue=0;
    >unsigned char mytest=0;
    >
    >mytest=0x34;
    >myvalue = mytest<<24;
    >
    >Then myvalue gets the value 0x1A000000!!!!!
    >How is this possible? Should'nt it be 0x34000000???


    Show us a minimal, but *complete* program illustrating your problem.
    Without seeing your code, not even my crystal ball is of much help here.
    Except for suggesting that the shift count was actually 23 in your real
    program.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Oct 9, 2003
    #5
  6. Jannick

    pete Guest

    Jannick wrote:
    >
    > Hi I have:
    > unsigned int myvalue=0;
    > unsigned char mytest=0;
    >
    > mytest=0x34;
    > myvalue = mytest<<24;
    >
    > Then myvalue gets the value 0x1A000000!!!!!
    > How is this possible? Should'nt it be 0x34000000???


    I guess we're all assuming that the width of unsigned,
    is at least 25 bits.
    Is it, on your system ?

    --
    pete
     
    pete, Oct 9, 2003
    #6
  7. "pete" <> schrieb im Newsbeitrag
    news:...
    > Jannick wrote:
    > >
    > > Hi I have:
    > > unsigned int myvalue=0;
    > > unsigned char mytest=0;
    > >
    > > mytest=0x34;
    > > myvalue = mytest<<24;
    > >
    > > Then myvalue gets the value 0x1A000000!!!!!
    > > How is this possible? Should'nt it be 0x34000000???

    >
    > I guess we're all assuming that the width of unsigned,
    > is at least 25 bits.
    > Is it, on your system ?


    Well, if myvalue becomes 0x1A000000 we can assume that, can we?
    And besides that, even if the width would be less than 24 the result would
    be well defined and definitely not 0x1a000000
    If I am not mistaken
    on all sizes up to and including 26 bits the value would be 0x0,
    27 and 28 bits will give 0x4000000,
    29 bits 0x14000000,
    30 bits and above 0x34000000

    kind regards
    Robert
     
    Robert Stankowic, Oct 9, 2003
    #7
  8. Jannick

    Dan Pop Guest

    In <3f856d52$0$32136$> "Robert Stankowic" <> writes:


    >"pete" <> schrieb im Newsbeitrag
    >news:...
    >> Jannick wrote:
    >> >
    >> > Hi I have:
    >> > unsigned int myvalue=0;
    >> > unsigned char mytest=0;
    >> >
    >> > mytest=0x34;
    >> > myvalue = mytest<<24;
    >> >
    >> > Then myvalue gets the value 0x1A000000!!!!!
    >> > How is this possible? Should'nt it be 0x34000000???

    >>
    >> I guess we're all assuming that the width of unsigned,
    >> is at least 25 bits.
    >> Is it, on your system ?

    >
    >Well, if myvalue becomes 0x1A000000 we can assume that, can we?


    We can safely assume 29 bits. Which makes a minimum of 32 bits a
    reasonable assumption. Pete should have engaged his brain before posting.

    >And besides that, even if the width would be less than 24 the result would
    >be well defined and definitely not 0x1a000000
    >If I am not mistaken
    >on all sizes up to and including 26 bits the value would be 0x0,
    >27 and 28 bits will give 0x4000000,
    >29 bits 0x14000000,
    >30 bits and above 0x34000000


    Wrong.

    If the value of the right operand is negative or is greater than or
    equal to the width in bits of the promoted left operand, the behavior
    is undefined.

    There was a long thread on this issue in comp.std.c, a few weeks ago.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Oct 9, 2003
    #8
  9. Jannick

    pete Guest

    Dan Pop wrote:
    >
    > In <3f856d52$0$32136$> "Robert Stankowic" <> writes:
    >
    > >"pete" <> schrieb im Newsbeitrag
    > >news:...
    > >> Jannick wrote:
    > >> >
    > >> > Hi I have:
    > >> > unsigned int myvalue=0;
    > >> > unsigned char mytest=0;
    > >> >
    > >> > mytest=0x34;
    > >> > myvalue = mytest<<24;
    > >> >
    > >> > Then myvalue gets the value 0x1A000000!!!!!
    > >> > How is this possible? Should'nt it be 0x34000000???
    > >>
    > >> I guess we're all assuming that the width of unsigned,
    > >> is at least 25 bits.
    > >> Is it, on your system ?

    > >
    > >Well, if myvalue becomes 0x1A000000 we can assume that, can we?

    >
    > We can safely assume 29 bits. Which makes a minimum of 32 bits a
    > reasonable assumption.
    > Pete should have engaged his brain before posting.


    A printf call could display 0x1A000000 with 16 bits and UB.

    --
    pete
     
    pete, Oct 10, 2003
    #9
  10. "Dan Pop" <> schrieb im Newsbeitrag
    news:bm3u7i$12l$...
    > In <3f856d52$0$32136$> "Robert

    Stankowic" <> writes:
    >
    >
    > >"pete" <> schrieb im Newsbeitrag
    > >news:...
    > >> Jannick wrote:
    > >> >
    > >> > Hi I have:
    > >> > unsigned int myvalue=0;
    > >> > unsigned char mytest=0;
    > >> >
    > >> > mytest=0x34;
    > >> > myvalue = mytest<<24;
    > >> >
    > >> > Then myvalue gets the value 0x1A000000!!!!!
    > >> > How is this possible? Should'nt it be 0x34000000???
    > >>
    > >> I guess we're all assuming that the width of unsigned,
    > >> is at least 25 bits.
    > >> Is it, on your system ?

    > >
    > >Well, if myvalue becomes 0x1A000000 we can assume that, can we?

    >
    > We can safely assume 29 bits. Which makes a minimum of 32 bits a
    > reasonable assumption. Pete should have engaged his brain before posting.
    >
    > >And besides that, even if the width would be less than 24 the result

    would
    > >be well defined and definitely not 0x1a000000
    > >If I am not mistaken
    > >on all sizes up to and including 26 bits the value would be 0x0,
    > >27 and 28 bits will give 0x4000000,
    > >29 bits 0x14000000,
    > >30 bits and above 0x34000000

    >
    > Wrong.
    >
    > If the value of the right operand is negative or is greater than or
    > equal to the width in bits of the promoted left operand, the behavior
    > is undefined.
    >


    So I obviously misunderstand the text from N869:

    "4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
    are filled with zeros. If E1 has an unsigned type, the value of the result
    is E1 x 2^E2, reduced modulo one more than the maximum value representable
    in the result type. If E1 has a signed type and nonnegative value, and E1 x
    2^E2 is representable in the result type, then that is the resulting value;
    otherwise, the behavior is undefined."

    The semicolon and the lower case "otherwise" suggested to me that the last
    phrase belongs to the sentence about signed types.
    Thank you for the clarification.
    kind regards
    Robert
     
    Robert Stankowic, Oct 10, 2003
    #10
  11. Jannick

    Jannick Guest

    "Dan Pop" <> wrote in message
    news:bm3k7e$mu7$...
    > In <bm3cko$qan$-c.dk> "Jannick" <> writes:
    >
    > >unsigned int myvalue=0;
    > >unsigned char mytest=0;
    > >
    > >mytest=0x34;
    > >myvalue = mytest<<24;
    > >
    > >Then myvalue gets the value 0x1A000000!!!!!
    > >How is this possible? Should'nt it be 0x34000000???

    >
    > Show us a minimal, but *complete* program illustrating your problem.
    > Without seeing your code, not even my crystal ball is of much help here.
    > Except for suggesting that the shift count was actually 23 in your real
    > program.
    >
    > Dan
    > --
    > Dan Pop
    > DESY Zeuthen, RZ group
    > Email:



    Here is my code. I would actually like to do the commented operation, but
    also with the code as it is it gives me the strange error :-(. The funny
    thing is that when I do measuredata.n1.number1<<16 I get ram_value =
    0x00340000, but when I do measuredata.n1.number1<<24 I get 0x1A000000. It
    seems to me that it actually only does measuredata.n1.number1<<23....I can
    seem to see why :-(

    Code:

    struct no1_{
    unsigned char number1;
    unsigned char number2;
    };

    struct no2_{
    unsigned int number3;
    unsigned int number4;
    };

    struct measurement_data{
    struct no1_ n1;
    struct no2_ n2;
    }measuredata;


    int main(){

    unsigned int* sram_location = (unsigned int *) 0xFF120011;

    measuredata.n1.number1 = 0x34;
    measuredata.n1.number2 = 0xBA;
    measuredata.n2.number3 = 0x12345678;
    measuredata.n2.number4 = 0xABCDEF12;
    mytest= 0x34;


    /* *sram_location = ( ((measuredata.n1.number1)<<24) | (
    (measuredata.n1.number2)<<16) | ( (measuredata.n2.number3)>>16) );*/

    ram_value = measuredata.n1.number1<<24;
    *sram_location = ram_value;

    return 0;
    }
     
    Jannick, Oct 10, 2003
    #11
  12. Jannick

    Dan Pop Guest

    In <> pete <> writes:

    >Dan Pop wrote:
    >>
    >> In <3f856d52$0$32136$> "Robert Stankowic" <> writes:
    >>
    >> >"pete" <> schrieb im Newsbeitrag
    >> >news:...
    >> >> Jannick wrote:
    >> >> >
    >> >> > Hi I have:
    >> >> > unsigned int myvalue=0;
    >> >> > unsigned char mytest=0;
    >> >> >
    >> >> > mytest=0x34;
    >> >> > myvalue = mytest<<24;
    >> >> >
    >> >> > Then myvalue gets the value 0x1A000000!!!!!
    >> >> > How is this possible? Should'nt it be 0x34000000???
    >> >>
    >> >> I guess we're all assuming that the width of unsigned,
    >> >> is at least 25 bits.
    >> >> Is it, on your system ?
    >> >
    >> >Well, if myvalue becomes 0x1A000000 we can assume that, can we?

    >>
    >> We can safely assume 29 bits. Which makes a minimum of 32 bits a
    >> reasonable assumption.
    >> Pete should have engaged his brain before posting.

    >
    >A printf call could display 0x1A000000 with 16 bits and UB.


    The probability of this happening is so close to that of nasal demon
    generation that it's not worth considering in the context of a *real*
    implementation.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Oct 10, 2003
    #12
  13. Jannick

    Dan Pop Guest

    In <3f861fe8$0$32136$> "Robert Stankowic" <> writes:


    >"Dan Pop" <> schrieb im Newsbeitrag
    >news:bm3u7i$12l$...
    >> In <3f856d52$0$32136$> "Robert

    >Stankowic" <> writes:
    >>
    >>
    >> >"pete" <> schrieb im Newsbeitrag
    >> >news:...
    >> >> Jannick wrote:
    >> >> >
    >> >> > Hi I have:
    >> >> > unsigned int myvalue=0;
    >> >> > unsigned char mytest=0;
    >> >> >
    >> >> > mytest=0x34;
    >> >> > myvalue = mytest<<24;
    >> >> >
    >> >> > Then myvalue gets the value 0x1A000000!!!!!
    >> >> > How is this possible? Should'nt it be 0x34000000???
    >> >>
    >> >> I guess we're all assuming that the width of unsigned,
    >> >> is at least 25 bits.
    >> >> Is it, on your system ?
    >> >
    >> >Well, if myvalue becomes 0x1A000000 we can assume that, can we?

    >>
    >> We can safely assume 29 bits. Which makes a minimum of 32 bits a
    >> reasonable assumption. Pete should have engaged his brain before posting.
    >>
    >> >And besides that, even if the width would be less than 24 the result

    >would
    >> >be well defined and definitely not 0x1a000000
    >> >If I am not mistaken
    >> >on all sizes up to and including 26 bits the value would be 0x0,
    >> >27 and 28 bits will give 0x4000000,
    >> >29 bits 0x14000000,
    >> >30 bits and above 0x34000000

    >>
    >> Wrong.
    >>
    >> If the value of the right operand is negative or is greater than or
    >> equal to the width in bits of the promoted left operand, the behavior
    >> is undefined.
    >>

    >
    >So I obviously misunderstand the text from N869:
    >
    >"4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
    >are filled with zeros. If E1 has an unsigned type, the value of the result
    >is E1 x 2^E2, reduced modulo one more than the maximum value representable
    >in the result type. If E1 has a signed type and nonnegative value, and E1 x
    >2^E2 is representable in the result type, then that is the resulting value;
    >otherwise, the behavior is undefined."
    >
    >The semicolon and the lower case "otherwise" suggested to me that the last
    >phrase belongs to the sentence about signed types.
    >Thank you for the clarification.


    The origin of your misunderstanding is the omission of reading paragraph
    3 *before* reading paragraph 4. Paragraph 3 contains the text I have
    quoted (actually a similar text, since I was quoting from C89).

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Oct 10, 2003
    #13
  14. Jannick

    Dan Pop Guest

    In <bm646n$ail$-c.dk> "Jannick" <> writes:

    >Here is my code. I would actually like to do the commented operation, but
    >also with the code as it is it gives me the strange error :-(. The funny
    >thing is that when I do measuredata.n1.number1<<16 I get ram_value =
    >0x00340000, but when I do measuredata.n1.number1<<24 I get 0x1A000000. It
    >seems to me that it actually only does measuredata.n1.number1<<23....I can
    >seem to see why :-(
    >
    >Code:
    >
    >struct no1_{
    > unsigned char number1;
    > unsigned char number2;
    >};
    >
    >struct no2_{
    > unsigned int number3;
    > unsigned int number4;
    >};
    >
    >struct measurement_data{
    > struct no1_ n1;
    > struct no2_ n2;
    >}measuredata;
    >
    >
    >int main(){
    >
    > unsigned int* sram_location = (unsigned int *) 0xFF120011;

    ^^^^^^^^^^
    This is a *very* suspicious address for an unsigned int! Are you sure
    you know what you're doing?

    > measuredata.n1.number1 = 0x34;
    > measuredata.n1.number2 = 0xBA;
    > measuredata.n2.number3 = 0x12345678;
    > measuredata.n2.number4 = 0xABCDEF12;
    > mytest= 0x34;
    >
    >
    > /* *sram_location = ( ((measuredata.n1.number1)<<24) | (
    >(measuredata.n1.number2)<<16) | ( (measuredata.n2.number3)>>16) );*/
    >
    > ram_value = measuredata.n1.number1<<24;
    > *sram_location = ram_value;
    >
    >return 0;
    >}


    Nope, this is NOT your code! It contains two undeclared identifiers,
    mytest and ram_value and it generates no output, so that we can actually
    see what happens. If I remove mytest, declare ram_value as unsigned int
    and display its value instead of dereferencing a dubious pointer, I get
    the following result:

    fangorn:~/tmp 544> gcc test.c
    fangorn:~/tmp 545> ./a.out
    34000000

    So, please don't waste our time with bogus pieces of code that neither
    compile nor illustrate your problem.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Oct 10, 2003
    #14
  15. Jannick

    CBFalconer Guest

    Jannick wrote:
    > "Dan Pop" <> wrote in message
    >

    .... snip ...
    > >
    > > Show us a minimal, but *complete* program illustrating your problem.
    > > Without seeing your code, not even my crystal ball is of much help here.
    > > Except for suggesting that the shift count was actually 23 in your real
    > > program.

    >
    > Here is my code. I would actually like to do the commented operation, but
    > also with the code as it is it gives me the strange error :-(. The funny
    > thing is that when I do measuredata.n1.number1<<16 I get ram_value =
    > 0x00340000, but when I do measuredata.n1.number1<<24 I get 0x1A000000. It
    > seems to me that it actually only does measuredata.n1.number1<<23....I can
    > seem to see why :-(
    >
    > Code:
    >
    > struct no1_{
    > unsigned char number1;
    > unsigned char number2;
    > };
    >
    > struct no2_{
    > unsigned int number3;
    > unsigned int number4;
    > };
    >
    > struct measurement_data{
    > struct no1_ n1;
    > struct no2_ n2;
    > }measuredata;
    >
    > int main(){
    >
    > unsigned int* sram_location = (unsigned int *) 0xFF120011;


    Undefined behavior here.

    >
    > measuredata.n1.number1 = 0x34;
    > measuredata.n1.number2 = 0xBA;
    > measuredata.n2.number3 = 0x12345678;
    > measuredata.n2.number4 = 0xABCDEF12;
    > mytest= 0x34;
    >
    > /* *sram_location = ( ((measuredata.n1.number1)<<24) | (
    > (measuredata.n1.number2)<<16) | ( (measuredata.n2.number3)>>16) );*/
    >
    > ram_value = measuredata.n1.number1<<24;
    > *sram_location = ram_value;
    >
    > return 0;
    > }


    Not a complete program. No way of displaying any fault. Illegal
    constructs. Why are you wasting our time with this?

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Oct 10, 2003
    #15
  16. Jannick

    Default User Guest

    CBFalconer wrote:

    > > unsigned int* sram_location = (unsigned int *) 0xFF120011;

    >
    > Undefined behavior here.



    Mmmmm, nope.


    [#5] An integer may be converted to any pointer type. |
    Except as previously specified, the result is
    implementation-defined, might not be properly aligned, and
    might not point to an entity of the referenced type.49)


    49)The mapping functions for converting a pointer to an
    integer or an integer to a pointer are intended to be
    consistent with the addressing structure of the execution
    environment.


    Assignment is ok. Use of it is problematic.



    Brian Rodenborn
     
    Default User, Oct 10, 2003
    #16
  17. Jannick

    Jannick Guest

    "Default User" <> wrote in message
    news:...
    > CBFalconer wrote:
    >
    > > > unsigned int* sram_location = (unsigned int *) 0xFF120011;

    > >
    > > Undefined behavior here.

    >
    >
    > Mmmmm, nope.
    >
    >
    > [#5] An integer may be converted to any pointer type. |
    > Except as previously specified, the result is
    > implementation-defined, might not be properly aligned, and
    > might not point to an entity of the referenced type.49)
    >
    >
    > 49)The mapping functions for converting a pointer to an
    > integer or an integer to a pointer are intended to be
    > consistent with the addressing structure of the execution
    > environment.
    >
    >
    > Assignment is ok. Use of it is problematic.
    >
    >
    >
    > Brian Rodenborn


    Sorry to post defective code....I was to quick in cutting the problem out of
    entire code... I think it is my compiler tricking me :-(, the "unsigned int*
    sram_location = (unsigned int *) 0xFF120011" is okay because the code is
    intended for a microcontroller that has a peripheral device memory-mapped at
    this location.

    I solved the problem though, but do still not understand it...I think the
    error lies in the compiler and dont think the error is easily seen. When I
    did:

    *sram_location = ( ((measuredata.n1.number1)<<24) | (
    (measuredata.n1.number2)<<16) | ( (measuredata.n2.number3)>>16) );

    I got the 0x1A000000

    When I do the:
    *sram_location = (
    ((measuredata.n1.number1<<16)<<8) | ((measuredata.n1.number2)<<16) | (
    (measuredata.n2.number3) >>16) );
    I get the correct result: 0x34000000

    Dont ask me why......

    Thank you all for your time, effort and patience.

    Best Regards
    Jannick
     
    Jannick, Oct 11, 2003
    #17
  18. "Dan Pop" <> schrieb im Newsbeitrag
    news:bm67l8$ekm$...
    > In <3f861fe8$0$32136$> "Robert

    Stankowic" <> writes:
    >
    >
    > >"Dan Pop" <> schrieb im Newsbeitrag

    [....]

    > The origin of your misunderstanding is the omission of reading paragraph
    > 3 *before* reading paragraph 4. Paragraph 3 contains the text I have
    > quoted (actually a similar text, since I was quoting from C89).


    Precise as always :)
    Thank you
    Robert
     
    Robert Stankowic, Oct 11, 2003
    #18
  19. Jannick

    CBFalconer Guest

    Jannick wrote:
    >

    .... snip ...
    >
    > Sorry to post defective code....I was to quick in cutting the
    > problem out of entire code... I think it is my compiler tricking
    > me :-(, the "unsigned int* sram_location = (unsigned int *)
    > 0xFF120011" is okay because the code is intended for a
    > microcontroller that has a peripheral device memory-mapped at
    > this location.
    >
    > I solved the problem though, but do still not understand it...I
    > think the error lies in the compiler and dont think the error is
    > easily seen. When I did:


    If you are writing into a section of memory mapped i/o, some of
    those locations are inputs. They can't be expected to store
    values.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Oct 11, 2003
    #19
  20. "Jannick" <> writes:
    [...]
    > Sorry to post defective code....I was to quick in cutting the problem out of
    > entire code... I think it is my compiler tricking me :-(, the "unsigned int*
    > sram_location = (unsigned int *) 0xFF120011" is okay because the code is
    > intended for a microcontroller that has a peripheral device memory-mapped at
    > this location.
    >
    > I solved the problem though, but do still not understand it...I think the
    > error lies in the compiler and dont think the error is easily seen. When I
    > did:
    >
    > *sram_location = ( ((measuredata.n1.number1)<<24) | (
    > (measuredata.n1.number2)<<16) | ( (measuredata.n2.number3)>>16) );
    >
    > I got the 0x1A000000
    >
    > When I do the:
    > *sram_location = (
    > ((measuredata.n1.number1<<16)<<8) | ((measuredata.n1.number2)<<16) | (
    > (measuredata.n2.number3) >>16) );
    > I get the correct result: 0x34000000
    >
    > Dont ask me why......


    The only difference (which would have been a lot clearer if you had
    formatted and indented the code more clearly) is the change from

    (measuredata.n1.number1)<<24

    to

    (measuredata.n1.number1<<16)<<8

    What happens when you display the values of those expressions in
    isolation? What are the types of number1, number2, number3, and
    *sram_location? What is the size of int on your platform?

    If number1 is an unsigned int, and unsigned int is 16 bits on your
    platform, you could be seeing undefined behavior because the right
    operand of the "<<" is greater than or equal to the size of the
    operand. If this is the problem, and you're trying to get an unsigned
    long result (at least 32 bits), you should cast each operand to unsigned
    long before shifting it:

    *sram_location =
    ( (unsigned long)measuredata.n1.number1 << 24 ) |
    ( (unsigned long)measuredata.n1.number2 << 16 ) |
    ( (unsigned long)measuredata.n2.number3 >> 16 );

    (On the other hand, if number3 is 16 bits, it doesn't make much sense
    to do a 16-bit right shift on it.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
     
    Keith Thompson, Oct 11, 2003
    #20
    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. Emilio

    Strangest Control behaviour ?!

    Emilio, Oct 15, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    329
    Emilio
    Oct 15, 2003
  2. Neo Geshel
    Replies:
    7
    Views:
    511
    Neo Geshel
    Jul 1, 2005
  3. luserXtrog

    lisp toy: strangest warning I've seen

    luserXtrog, May 11, 2009, in forum: C Programming
    Replies:
    23
    Views:
    985
    luserXtrog
    May 17, 2009
  4. Mike

    Problem problem problem :( Need Help

    Mike, May 7, 2004, in forum: ASP General
    Replies:
    2
    Views:
    562
    Bullschmidt
    May 11, 2004
  5. Trans
    Replies:
    2
    Views:
    118
    Trans
    Aug 19, 2005
Loading...

Share This Page