The strangest problem....

[Jannick]

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

[Allan Bruce]

"Jannick" <Ja*@janse.dk> wrote in message
news:bm**********@news.net.uni-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

[Robert Stankowic]

"Jannick" <Ja*@janse.dk> schrieb im Newsbeitrag
news:bm**********@news.net.uni-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

[hongky]

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

"Jannick" <Ja*@janse.dk> wrote in message
news:bm**********@news.net.uni-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

[Dan Pop]

In <bm**********@news.net.uni-c.dk> "Jannick" <Ja*@janse.dk> 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: Da*****@ifh.de

[pete]

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

[Robert Stankowic]

"pete" <pf*****@mindspring.com> schrieb im Newsbeitrag
news:3F***********@mindspring.com...

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

[Dan Pop]

In <3f***********************@newsreader02.highway.te lekom.at> "Robert Stankowic" <pc******@netway.at> writes:

"pete" <pf*****@mindspring.com> schrieb im Newsbeitrag
news:3F***********@mindspring.com...

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: Da*****@ifh.de

[pete]

Dan Pop wrote:

In <3f***********************@newsreader02.highway.te lekom.at> "Robert Stankowic" <pc******@netway.at> writes:

"pete" <pf*****@mindspring.com> schrieb im Newsbeitrag
news:3F***********@mindspring.com...

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

[Robert Stankowic]

"Dan Pop" <Da*****@cern.ch> schrieb im Newsbeitrag
news:bm**********@sunnews.cern.ch...

In <3f***********************@newsreader02.highway.te lekom.at> "Robert Stankowic" <pc******@netway.at> writes:

"pete" <pf*****@mindspring.com> schrieb im Newsbeitrag
news:3F***********@mindspring.com...

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 wouldbe 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

[Jannick]

"Dan Pop" <Da*****@cern.ch> wrote in message
news:bm**********@sunnews.cern.ch...

In <bm**********@news.net.uni-c.dk> "Jannick" <Ja*@janse.dk> 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: Da*****@ifh.de

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;
}

[Dan Pop]

In <3F***********@mindspring.com> pete <pf*****@mindspring.com> writes:

Dan Pop wrote:

In <3f***********************@newsreader02.highway.te lekom.at> "Robert Stankowic" <pc******@netway.at> writes:

>"pete" <pf*****@mindspring.com> schrieb im Newsbeitrag
>news:3F***********@mindspring.com...
>> 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: Da*****@ifh.de

[Dan Pop]

In <3f***********************@newsreader02.highway.te lekom.at> "Robert Stankowic" <pc******@netway.at> writes:

"Dan Pop" <Da*****@cern.ch> schrieb im Newsbeitrag
news:bm**********@sunnews.cern.ch...

In <3f***********************@newsreader02.highway.te lekom.at> "Robert

Stankowic" <pc******@netway.at> writes:

>"pete" <pf*****@mindspring.com> schrieb im Newsbeitrag
>news:3F***********@mindspring.com...
>> 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 resultwould >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: Da*****@ifh.de

[Dan Pop]

In <bm**********@news.net.uni-c.dk> "Jannick" <Ja*@janse.dk> 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: Da*****@ifh.de

[CBFalconer]

Jannick wrote:

"Dan Pop" <Da*****@cern.ch> 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 (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Default User]

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

[Jannick]

"Default User" <fi********@boeing.com.invalid> wrote in message
news:3F***************@boeing.com.invalid...

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

[Robert Stankowic]

"Dan Pop" <Da*****@cern.ch> schrieb im Newsbeitrag
news:bm**********@sunnews.cern.ch...

In <3f***********************@newsreader02.highway.te lekom.at> "Robert Stankowic" <pc******@netway.at> writes:

"Dan Pop" <Da*****@cern.ch> 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

[CBFalconer]

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 (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Mattias Ekholm]

Hi

The error is indeed a compiler fault! Don't bother what every one else
says. I encountered the same problem with an Alpha processor.

The problem is that the shift assembler instruction with immediate
oparand are only able to contain left shift values up to 23 (all bit
sets in operand field), try investigate the assebler manual for details.

The compiler failes to identify the need for storing the operand in a
register instead.

kind regards
Mattias Ekholm
Jannick wrote:

"Default User" <fi********@boeing.com.invalid> wrote in message
news:3F***************@boeing.com.invalid...

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

[Dan Pop]

In <3F***************@boeing.com.invalid> Default User <fi********@boeing.com.invalid> writes:

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.

Nope. There is more to it. First, the quote from the final standard is:

5 An integer may be converted to any pointer type. Except as
previously specified, the result is implementation-defined,
might not be correctly aligned, might not point to an entity of
the referenced type, and might be a trap representation.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Assigning a trap representation *is* undefined behaviour. And two
paragraphs later:

7 A pointer to an object or incomplete type may be converted to
a pointer to a different object or incomplete type. If the
resulting pointer is not correctly aligned 57) for the pointed-to
type, the behavior is undefined.

which says that the mere generation of a misaligned pointer invokes
undefined behaviour (it's true that the generation was via a different
mechanism, however).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <jj********************@newsc.telia.net> Mattias Ekholm <ne**@ekholm.se> writes:

Hi

The error is indeed a compiler fault! Don't bother what every one else
says. I encountered the same problem with an Alpha processor.

The problem is that the shift assembler instruction with immediate
oparand are only able to contain left shift values up to 23 (all bit
sets in operand field), try investigate the assebler manual for details.

Nonsense: 24 is NOT a power of two, therefore all bits set in the operand
field cannot encode a value of 23. With an operand field of 4 bits, the
limit is 15, with an operand field of 5 bits, the limit is 31.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Default User]

Dan Pop wrote:

In <3F***************@boeing.com.invalid> Default User <fi********@boeing.com.invalid> writes:

Assignment is ok. Use of it is problematic.

Nope. There is more to it. First, the quote from the final standard is:

5 An integer may be converted to any pointer type. Except as
previously specified, the result is implementation-defined,
might not be correctly aligned, might not point to an entity of
the referenced type, and might be a trap representation.

Ah yes, that does make a difference.

which says that the mere generation of a misaligned pointer invokes
undefined behaviour (it's true that the generation was via a different
mechanism, however).

I guess it comes down to "possibly undefined behavior". My reading was
that it was safe to generate the construct, but not to use except in
implementation-specific ways. Looks like that's not correct.

Thanks for the correction.

Brian Rodenborn

[Glen Herrmannsfeldt]

"Jannick" <Ja*@janse.dk> wrote in message
news:bm**********@news.net.uni-c.dk...

(snip)

*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

What type of machine is this? It is much easier to answer if we know.

Note that shifting greater than or equal to the number of bits in an
unsigned int is implementation defined. On a 24 bit machine, this may be
the right answer. Is it a 24 bit machine?

-- glen

[Dan Pop]

In <oW********************@rwcrnsc52.ops.asp.att.ne t> "Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes:

"Jannick" <Ja*@janse.dk> wrote in message
news:bm**********@news.net.uni-c.dk...

(snip)

*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

What type of machine is this? It is much easier to answer if we know.

Note that shifting greater than or equal to the number of bits in an
unsigned int is implementation defined. On a 24 bit machine, this may be
the right answer. Is it a 24 bit machine?

If it were, how would you explain an output of 0x1A000000, which *cannot*
be represented in 24 bits? Have you forgotten your brain in neutral? ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Glen Herrmannsfeldt]

"Dan Pop" <Da*****@cern.ch> wrote in message
news:bm*********@sunnews.cern.ch...

In <oW********************@rwcrnsc52.ops.asp.att.ne t> "Glen

Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes:

(snip)

What type of machine is this? It is much easier to answer if we know.

Note that shifting greater than or equal to the number of bits in an
unsigned int is implementation defined. On a 24 bit machine, this may be
the right answer. Is it a 24 bit machine?

If it were, how would you explain an output of 0x1A000000, which *cannot*
be represented in 24 bits? Have you forgotten your brain in neutral? ;-)

That is a good question. It does seem, though, that there are machines that
use different widths for different operations. Some CDC machine will do
addition to full 60 bit register width, but multiplication only to 48, or
so. As far as C, it would have to be considered 48 bits, presumably with
12 padding bits.

It is hard to say that anyone would, or would not, limit the shift amount to
less than the full register width, yet still shift all the bits. Most that
I know, take the shift value modulo the register size, but that isn't
required. Especially not with 24 bit or 60 bit registers.

He seems to be reporting values stored in memory, instead of printing them
using C library functions.

It would be much easier to say knowing what the processor was. I believe
the 56001 is a 24 bit processor, but I don't know at all how it does shifts.

-- glen

[Dan Pop]

In <t%********************@rwcrnsc51.ops.asp.att.ne t> "Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes:

"Dan Pop" <Da*****@cern.ch> wrote in message
news:bm*********@sunnews.cern.ch...

In <oW********************@rwcrnsc52.ops.asp.att.ne t> "Glen

Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes:

(snip)

>What type of machine is this? It is much easier to answer if we know.
>
>Note that shifting greater than or equal to the number of bits in an
>unsigned int is implementation defined. On a 24 bit machine, this may be
>the right answer. Is it a 24 bit machine?

If it were, how would you explain an output of 0x1A000000, which *cannot*
be represented in 24 bits? Have you forgotten your brain in neutral? ;-)

It would be much easier to say knowing what the processor was. I believe
the 56001 is a 24 bit processor, but I don't know at all how it does shifts.

Not relevant, since we have direct proof that he's using a processor with
more than 24 bits, according to the 0x1A000000 result.

A *proper* C program illustrating the problem would probably help in
figuring out what is going on.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de