«

Hi,

If I typecast a byte to a long integer in different endian (Big &
Little endian) systems does it behave differently.

I am confused between the following.
If the address of the byte is 0 then seeing the address as long should
be different in big and little endian systems.
or
As the language is portable,long will have the same value when you see
it in little or big endian systems

Thanks
Regards
Rupesh Kumar

On May 21, 10:14 am, Rupesh Kumar <a.rupes...@gmail.com> wrote:
> Hi,
>
> If I typecast a byte to a long integer in different endian (Big &
> Little endian) systems does it behave differently.
>
> I am confused between the following.
> If the address of the byte is 0 then seeing the address as long should
> be different in big and little endian systems.
> or
> As the language is portable,long will have the same value when you see
> it in little or big endian systems

Now it is appearing more clear to me.
1. If the char is typecast to long then the char value is get into
register and it will be assigned to the long variable so it should be
same in both endian systems.
2. As I was earlier thinking like if you see the address 0 in big and
endian systems it gives different values. This is also correct but
type casting doesnt care address of char.
Anyway typecasting char address to long pointer may make the long
pointer unaligned.

Correct me if I am wrong.

Thanks
Regards
Rupesh Kumar

Rupesh Kumar <> writes:
> If I typecast a byte to a long integer in different endian (Big &
> Little endian) systems does it behave differently.

No. But first, some answers to questions you didn't ask.

The term is "cast", not "typecast". A cast is an operator, consisting
of a type name in parentheses, that specifies a conversion. And in
most cases, whatever conversion you want will be performed implicitly;
a cast is unnecessary and, in some cases, dangerous.

For example:

unsigned char one_byte = 42;
long foo = one_byte; /* implicit conversion from unsigned char to long */

The value of foo will be 42. The representation of either char or
long is irrelevant. Conversions are defined to operate on values, not
on representations.

> I am confused between the following.
> If the address of the byte is 0 then seeing the address as long should
> be different in big and little endian systems.
> or
> As the language is portable,long will have the same value when you see
> it in little or big endian systems

Here, and in your followup, you talk about addresses, which makes me
wonder whether you're really asking about integer conversions (say,
from unsigned char to long) or about pointer conversions. Pointer
conversions can be used to implement what's called "type punning",
whereby an object of one type is treated as if it were of another
type. This does depend on the representation, and it can be dangerous
(and it's usually unnecessary). For example:

unsigned char one_byte = 42;
unsigned char *byte_addr = &one_byte;
long *long_addr = (long*)byte_addr; /* dangerous */
long foo = *long_addr; /* dangerous */

Here the code is looking at the object one_byte *as if* it were of
type long. Since it isn't, this can go bad in a number of ways. The
address of one_byte might not have the right alignment for type long,
and even if it's aligned correctly you're (almost certainly) looking
at bytes that aren't part of the object.

What are you actually trying to do?

--
Keith Thompson (The_Other_Keith) kst- <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"

Rupesh Kumar <> wrote:
>If I typecast a byte to a long integer in different endian (Big &
>Little endian) systems does it behave differently.

It should be portable as the long can almost undoubtedly hold the value
in the char. It will be converted; endinnesss isn't an issue.

(Question for the pros: what if CHAR_BIT is 32, and unsigned char
0xffffffff is stored in a long where LONG_MAX is +2147483647?)

>I am confused between the following. If the address of the byte is 0
>then seeing the address as long should be different in big and little
>endian systems.

I'm a little confused by it, too. But I think maybe what you're getting
at is this:

unsigned short x = 0xff00; // two-byte shorts, say

On a little-endian system, this would be stored as bytes:

00 ff

while on a big-endian system, it would be stored as bytes:

ff 00

So now let's add some code:

unsigned short x = 0xff00;
unsigned char *p = (unsigned char *)&x;

printf("%02hhx\n", *p); // prints "00" on my little-endian system

The address of x converted to unsigned char * is the first byte of x,
and, as seen above, that can be 00 or ff depending on the machine's
endianness.

-Beej

Beej Jorgensen <> writes:
> Rupesh Kumar <> wrote:
>>If I typecast a byte to a long integer in different endian (Big &
>>Little endian) systems does it behave differently.
>
> It should be portable as the long can almost undoubtedly hold the value
> in the char. It will be converted; endinnesss isn't an issue.
>
> (Question for the pros: what if CHAR_BIT is 32, and unsigned char
> 0xffffffff is stored in a long where LONG_MAX is +2147483647?)

The conversion yields an implementation-defined result or (new in C99)
raises an implementation-defined signal. C99 6.3.1.3p3.

[...]

--
Keith Thompson (The_Other_Keith) kst- <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"

> Here, and in your followup, you talk about addresses, which makes me
> wonder whether you're really asking about integer conversions (say,
> from unsigned char to long) or about pointer conversions. Pointer
> conversions can be used to implement what's called "type punning",
> whereby an object of one type is treated as if it were of another
> type. This does depend on the representation, and it can be dangerous
> (and it's usually unnecessary). For example:
>
> unsigned char one_byte = 42;
> unsigned char *byte_addr = &one_byte;
> long *long_addr = (long*)byte_addr; /* dangerous */
> long foo = *long_addr; /* dangerous */
>
> Here the code is looking at the object one_byte *as if* it were of
> type long. Since it isn't, this can go bad in a number of ways. The
> address of one_byte might not have the right alignment for type long,
> and even if it's aligned correctly you're (almost certainly) looking
> at bytes that aren't part of the object.
>
> What are you actually trying to do?
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
> Nokia


I was talking about integer conversions only but I got confused it
with pointer conversions.
Your explanation clears all of my doubts.

Thanks a lot.

Regards
Rupesh Kumar

On Wed, 20 May 2009 22:14:27 -0700 (PDT), Rupesh Kumar
<> wrote:

>Hi,
>
>If I typecast a byte to a long integer in different endian (Big &
>Little endian) systems does it behave differently.
>
>I am confused between the following.
>If the address of the byte is 0 then seeing the address as long should
>be different in big and little endian systems.
>or
>As the language is portable,long will have the same value when you see
>it in little or big endian systems
>
>Thanks
>Regards
>Rupesh Kumar

Wrong for two reasons.
Endian-ness is related to one target machine at a time. And the
machine hardware takes care of it in a consistent fashion (else it
would not work).
Any (very minor) endian-ness not already handled by the hardware is
done by the compiler at compile time, at a level well below the
written "C".
Q.E.D. There is no endian issue at the "C" level, on any one target
machine at any time.

On 29 May, 02:55, "JosephKK"<quiettechb...@yahoo.com> wrote:
> On Wed, 20 May 2009 22:14:27 -0700 (PDT), Rupesh Kumar
> <a.rupes...@gmail.com> wrote:

> >If I [cast] a byte to a long integer in different endian (Big &
> >Little endian) systems does it behave differently.

yes-ish though you might get Undefined Behaviour

unsigned char b = 1;
long ll;

ll = (long)b;

this may give you UB as b may not be correctly aligned to be used
as a long.

This will give different behaviours depending on endianess

long ll = 1;
unsigned char b;

b = (unsigned char)ll;

printf ("%d\n", b);

may print either 0 or 1


> >I am confused between the following.
> >If the address of the byte is 0 then seeing the address as long should
> >be different in big and little endian systems.

yep

> >or
> >As the language is portable,long will have the same value when you see
> >it in little or big endian systems

yes but casting gets you to the underlying implementaion.
By casting something to unsigned char you get implementation
defined behaviour (casting to other things may get you
undefined behaviour- this *might* crash your program).


> Wrong for two reasons. *

no. not wrong


> Endian-ness is related to one target machine at a time.

some hardware can change endianess on-the-fly. Though
I agree it's hard to see how a c impleemntaion could deal with this!

> *And the
> machine hardware takes care of it in a consistent fashion (else it
> would not work).

no-ish

> Any (very minor) endian-ness

what is "minor endianess". Are only some of the bits endianised?

> not already handled by the hardware is
> done by the compiler at compile time, at a level well below the
> written "C".

no

> Q.E.D. There is no endian issue at the "C" level, on any one target
> machine at any time

define "C level". You are misleading a newbie.


--
Nick Keighley

"The Dinosaurs have come and gone,
we Theriodonts remain"

On 29 May, 11:00, Richard <rgrd...@gmail.com> wrote:
> Richard Heathfield <r...@see.sig.invalid> writes:
> > nick_keighley_nos...@hotmail.com said:
> >> On 29 May, 02:55, "JosephKK"<quiettechb...@yahoo.com> wrote:
> >>> On Wed, 20 May 2009 22:14:27 -0700 (PDT), Rupesh Kumar
> >>> <a.rupes...@gmail.com> wrote:


> >>> >If I [cast] a byte to a long integer in different endian (Big &
> >>> >Little endian) systems does it behave differently.
>
> >> yes-ish though you might get Undefined Behaviour
>
> >> * *unsigned char b = 1;
> >> * *long ll;
>
> >> * *ll = (long)b;
>
> >> this may give you UB as b may not be correctly aligned to be used
> >> as a long.
>
> > Chapter and verse, please. Translation: I think you're talking
> > through your nose.

Or possibly some other bit of my anatomy

> > The value of b is 1, and 1 is in the range that can be represented
> > by a long, so casting it to long is harmless (and pointless). It
> > results in the value 1. Values do not *have* alignments, so
> > alignment is a non-issue here.
>
> Thank God for that.
>
> So Mr Keighley, a little egg to wipe off today after calling me a troll
> and then cocking up hugely only to be questioned on it by .... me.
>
> Enjoy that humble pie.

Egg and humble pie!

I was entirely wrong. I also owe JosephKK an apology.

What I was thinking of was this:-

long ll = 1;
unsigned char *b;

b = (unsigned char*)&ll;
printf ("%d\n", *b);

And for the record, richard <no-name>, I said you sometimes trolled.
Not that everything you said was wrong or technically uninteresting.

Keith Thompson <kst-> writes:
> The term is "cast", not "typecast".

I stand corrected.

You used "type casting", which has precedent in the Rationale.

Sorry to be a bother. =) Ignore the rest of my post as well.

--
Keith Thompson (The_Other_Keith) kst- <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"