help signed and unsigned in 64bits

[amit]

Hi,

What will happen in following scenario..
long a = -2;
longlong b = a

long c;
c = *(ulonglong *)&b;
b = c;
also when
long d;
d = *&b;
b = d;
What will be the value of b ? When will it lose the upper 32bits ?

regards
amit

[Leor Zolman]

On 6 Apr 2004 17:44:38 -0700, an******@yahoo. com (amit) wrote:

Hi,

What will happen in following scenario..
long a = -2;
longlong b = a

long c;
c = *(ulonglong *)&b;
b = c;
also when
long d;
d = *&b;
b = d;
What will be the value of b ? When will it lose the upper 32bits ?

regards
amit

Let me know if I've misinterpreted anything you wrote up there:

#include <stdio.h>

int main()
{
long a = -2;

printf("a = %ld\n", a);
printf("a (unsigned) = %uld\n\n", a);

long long b = a;
printf("b = %lld\n", b);
printf("b (unsigned) = %llu\n\n", b);

long c;
c = *(unsigned long long *)&b;
printf("c (via pointers) = %ld\n", c);
printf("c (via pointers, unsigned) = %uld\n\n", c);

/* I've added this (why bother with the pointers? */
c = (unsigned long long) b;
printf("c (no pointers) = %ld\n", c);
printf("c (no pointers, unsigned) = %uld\n\n", c);

b = c;
long d;
d = *&b;
printf("d = %ld\n", d);
printf("d (unsigned) = %uld\n\n", d);

b = d;
printf("b (from d) = %lld\n", b);
printf("b (from d) (unsigned) = %llu\n\n", b);

b = (unsigned) d;
printf("b (from unsigned d) = %lld\n", b);
printf("b (from unsigned d) (unsigned) = %llu\n\n", b);
return 0;
}

Output:
a = -2
a (unsigned) = 4294967294ld

b = -2
b (unsigned) = 184467440737095 51614

c (via pointers) = -2
c (via pointers, unsigned) = 4294967294ld

c (no pointers) = -2
c (no pointers, unsigned) = 4294967294ld

d = -2
d (unsigned) = 4294967294ld

b (from d) = -2
b (from d) (unsigned) = 184467440737095 51614

b (from unsigned d) = 4294967294
b (from unsigned d) (unsigned) = 4294967294

So note that you do lose finally lose the upper 32 bits when assigning from
d to c, /if/ you first cast d's value to unsigned. So long as you're doing
the assignment as a signed value, you'll get sign extension.

(Compiled with Comeau 4.3.3, Dinkum Unabridged Library)
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On 6 Apr 2004 17:44:38 -0700, an******@yahoo. com (amit) wrote:

Hi,

What will happen in following scenario..
long a = -2;
longlong b = a

long c;
c = *(ulonglong *)&b;
b = c;
also when
long d;
d = *&b;
b = d;
What will be the value of b ? When will it lose the upper 32bits ?

regards
amit

Let me know if I've misinterpreted anything you wrote up there:

#include <stdio.h>

int main()
{
long a = -2;

printf("a = %ld\n", a);
printf("a (unsigned) = %uld\n\n", a);

long long b = a;
printf("b = %lld\n", b);
printf("b (unsigned) = %llu\n\n", b);

long c;
c = *(unsigned long long *)&b;
printf("c (via pointers) = %ld\n", c);
printf("c (via pointers, unsigned) = %uld\n\n", c);

/* I've added this (why bother with the pointers? */
c = (unsigned long long) b;
printf("c (no pointers) = %ld\n", c);
printf("c (no pointers, unsigned) = %uld\n\n", c);

b = c;
long d;
d = *&b;
printf("d = %ld\n", d);
printf("d (unsigned) = %uld\n\n", d);

b = d;
printf("b (from d) = %lld\n", b);
printf("b (from d) (unsigned) = %llu\n\n", b);

b = (unsigned) d;
printf("b (from unsigned d) = %lld\n", b);
printf("b (from unsigned d) (unsigned) = %llu\n\n", b);
return 0;
}

Output:
a = -2
a (unsigned) = 4294967294ld

b = -2
b (unsigned) = 184467440737095 51614

c (via pointers) = -2
c (via pointers, unsigned) = 4294967294ld

c (no pointers) = -2
c (no pointers, unsigned) = 4294967294ld

d = -2
d (unsigned) = 4294967294ld

b (from d) = -2
b (from d) (unsigned) = 184467440737095 51614

b (from unsigned d) = 4294967294
b (from unsigned d) (unsigned) = 4294967294

So note that you do lose finally lose the upper 32 bits when assigning from
d to c, /if/ you first cast d's value to unsigned. So long as you're doing
the assignment as a signed value, you'll get sign extension.

(Compiled with Comeau 4.3.3, Dinkum Unabridged Library)
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On Wed, 07 Apr 2004 01:13:59 GMT, Leor Zolman <le**@bdsoft.co m> wrote:

Well, that was my very first time attempting to display values of long
longs, and in my confusion I ended up with a spurious "d" in four format
conversions (I put %uld when %ul was sufficient for a plain unsigned long).

Fortunately, that didn't really break the output, except that there's a
trailing, meaningless 'd' at the end of 4 of the lines. Sorry about that.
-leor

P.S. It took me a while to find a platform that displayed long long values
at all! Good thing I had that Dinkum lib lying around... ;-)

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On Wed, 07 Apr 2004 01:13:59 GMT, Leor Zolman <le**@bdsoft.co m> wrote:

Well, that was my very first time attempting to display values of long
longs, and in my confusion I ended up with a spurious "d" in four format
conversions (I put %uld when %ul was sufficient for a plain unsigned long).

Fortunately, that didn't really break the output, except that there's a
trailing, meaningless 'd' at the end of 4 of the lines. Sorry about that.
-leor

P.S. It took me a while to find a platform that displayed long long values
at all! Good thing I had that Dinkum lib lying around... ;-)

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Jack Klein]

On 6 Apr 2004 17:44:38 -0700, an******@yahoo. com (amit) wrote in
comp.lang.c:

Hi,

What will happen in following scenario..
long a = -2;
longlong b = a

long c;
c = *(ulonglong *)&b;
The result of the assignment is implementation-defined, or, under C99,
for some strange reason, there is the alternative possibility that an
implementation-defined signal will be raised.
b = c;
also when
long d;
d = *&b;
Again, the result is implementation-defined.
b = d;
What will be the value of b ? When will it lose the upper 32bits ?
You will need to try it on your compiler to find out, or consult the
compiler's documentation. You are assigning a value to a signed
integer type from a wider type when the value of the wider type is
outside the range of the destination signed type. The C standard does
not specify the result, only that it is implementation-defined. That
means the compiler must document what it does.

And there is no guarantee that long long has 32 more bits than long,
of course.
regards
amit

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On 6 Apr 2004 17:44:38 -0700, an******@yahoo. com (amit) wrote in
comp.lang.c:

Hi,

What will happen in following scenario..
long a = -2;
longlong b = a

long c;
c = *(ulonglong *)&b;
The result of the assignment is implementation-defined, or, under C99,
for some strange reason, there is the alternative possibility that an
implementation-defined signal will be raised.
b = c;
also when
long d;
d = *&b;
Again, the result is implementation-defined.
b = d;
What will be the value of b ? When will it lose the upper 32bits ?
You will need to try it on your compiler to find out, or consult the
compiler's documentation. You are assigning a value to a signed
integer type from a wider type when the value of the wider type is
outside the range of the destination signed type. The C standard does
not specify the result, only that it is implementation-defined. That
means the compiler must document what it does.

And there is no guarantee that long long has 32 more bits than long,
of course.
regards
amit

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Leor Zolman]

On Tue, 06 Apr 2004 20:45:25 -0500, Jack Klein <ja*******@spam cop.net>
wrote:

You will need to try it on your compiler to find out, or consult the
compiler's documentation. You are assigning a value to a signed
integer type from a wider type when the value of the wider type is
outside the range of the destination signed type. The C standard does
not specify the result, only that it is implementation-defined. That
means the compiler must document what it does.

And there is no guarantee that long long has 32 more bits than long,
of course.
Of course (not that it even occurred to me, because even with my new locker
and badge I still don't always think in terms of "the general case" when
faced with questions like this) this is all accurate in terms of the
Standard.

I began with the assumption the OP's long long was really longer than his
long (watch it, Richard!) and that he was interested in issues such as the
ones I tried to highlight in my test program. I'm kind of hoping he finds
/both/ analyses to be useful...
-leor

regards
amit

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On Tue, 06 Apr 2004 20:45:25 -0500, Jack Klein <ja*******@spam cop.net>
wrote:

You will need to try it on your compiler to find out, or consult the
compiler's documentation. You are assigning a value to a signed
integer type from a wider type when the value of the wider type is
outside the range of the destination signed type. The C standard does
not specify the result, only that it is implementation-defined. That
means the compiler must document what it does.

And there is no guarantee that long long has 32 more bits than long,
of course.
Of course (not that it even occurred to me, because even with my new locker
and badge I still don't always think in terms of "the general case" when
faced with questions like this) this is all accurate in terms of the
Standard.

I began with the assumption the OP's long long was really longer than his
long (watch it, Richard!) and that he was interested in issues such as the
ones I tried to highlight in my test program. I'm kind of hoping he finds
/both/ analyses to be useful...
-leor

regards
amit

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Jack Klein]

On Wed, 07 Apr 2004 01:54:43 GMT, Leor Zolman <le**@bdsoft.co m> wrote
in comp.lang.c:

On Tue, 06 Apr 2004 20:45:25 -0500, Jack Klein <ja*******@spam cop.net>
wrote:

You will need to try it on your compiler to find out, or consult the
compiler's documentation. You are assigning a value to a signed
integer type from a wider type when the value of the wider type is
outside the range of the destination signed type. The C standard does
not specify the result, only that it is implementation-defined. That
means the compiler must document what it does.

And there is no guarantee that long long has 32 more bits than long,
of course.

Of course (not that it even occurred to me, because even with my new locker
and badge I still don't always think in terms of "the general case" when
faced with questions like this) this is all accurate in terms of the
Standard.

I began with the assumption the OP's long long was really longer than his
long (watch it, Richard!) and that he was interested in issues such as the
ones I tried to highlight in my test program. I'm kind of hoping he finds
/both/ analyses to be useful...
-leor

Your test program was actually an excellent idea. One way to
determine implementation-defined results with a particular compiler is
to test it. And since the OP's question involved only
implementation-defined, and not undefined, behavior, a test is quite
practical.

The only thing the OP needs to remember is that he should compile and
run your test program on his implementation, where the results he gets
might or might not be the same as those you got.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html