help signed and unsigned in 64bits

A

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
 
L

Leor Zolman

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) = 18446744073709551614

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) = 18446744073709551614

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
 
L

Leor Zolman

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... ;-)
 
J

Jack Klein

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.
 
L

Leor Zolman

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
 
J

Jack Klein

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.
 
C

CBFalconer

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

The compiler complains about a syntax error.
long c;
c = *(ulonglong *)&b;

Another syntax error.
b = c;
also when
long d;
d = *&b;
b = d;
What will be the value of b ? When will it lose the upper 32bits ?

Since things don't compile, the remainder of the question is
meaningless. You should consider the use and meaning of the blank
character.
 
J

jacob navia

You get the same results if you use lcc-win32.
lcc-win32 supports long long since quite a while
now.
 
L

Leor Zolman

You get the same results if you use lcc-win32.
lcc-win32 supports long long since quite a while
now.

Thanks, Jacob, I didn't even know about your compiler. I've been
"collecting" C++ compilers (for STLFilt development work), but for C I've
just been relying on the ones (such as Comeau) that come "free" with C++
and have done the best job of diagnosing things. I'll get lcc-win32 and
play with it.
-leor
 
L

Leor Zolman

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... ;-)

You're all way too polite (heh), I can't believe no one has posted yet to
give me hell. To set the record straight, I do in fact realize that those
conversions I originally wrote as "%uld", then corrected to "%ul", should
actually be "%lu". The consistency between long and long long conversion
syntax is way too sensible for me to have thought of trying it first, and
then bad eyesight must have made me think the ells before the d's were
ones...
-leor
 
D

Dan Pop

In said:
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).

Bzzzt, still wrong. The *correct* conversion descriptor for unsigned long
is, and has always been, %lu. %ul expects an unsigned int and appends an
'l' to its value. If it receives an unsigned long, undefined behaviour.
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.

It broke everything, due to invoking undefined behaviour, so any output
you got was by accident, rather than by design.
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... ;-)

It's been a common Unix extension for ages...

Dan
 
L

Leor Zolman

Bzzzt, still wrong. The *correct* conversion descriptor for unsigned long
is, and has always been, %lu. %ul expects an unsigned int and appends an
'l' to its value. If it receives an unsigned long, undefined behaviour.

I guess at least technically, I don't need to say "I spoke too soon" :)
It broke everything, due to invoking undefined behaviour, so any output
you got was by accident, rather than by design.


It's been a common Unix extension for ages...

I only use Unix for teaching Unix and making tar files (and for the
latter, Cgwin actually...)
-leor
 
C

CBFalconer

Leor said:
.... snip ...

I only use Unix for teaching Unix and making tar files (and for
the latter, Cgwin actually...)

Try DJGPP. Much faster. Does all those things.
 
L

Leor Zolman

Try DJGPP. Much faster. Does all those things.

Oh, I have that here. Not sure I ever realized it does C. I got the gcc
version of STLFilt (for C++ of course) supporting djgpp back in 2002...and
I just realized that nowhere in my docs is that fact actually documented.
That's because I just think of djgpp as "yet another gcc clone", and
figured everyone else would probably know that its messages would be the
same as those of "vanilla" gcc. Foo. Thanks for the heads up!
-leor
 
D

Dan Pop

In said:
I only use Unix for teaching Unix and making tar files (and for the
latter, Cgwin actually...)
^^^^^^^^^^^^^^
Cygwin's gcc and libraries have supported long long forever, so you had
such a platform right under your nose ;-)

Dan
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top