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

[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

[CBFalconer]

amit wrote:

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.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[CBFalconer]

amit wrote:

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.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[jacob navia]

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

[jacob navia]

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

[Leor Zolman]

On Wed, 7 Apr 2004 08:55:10 +0200, "jacob navia" <ja***@jacob.re mcomp.fr>
wrote:

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
--
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, 7 Apr 2004 08:55:10 +0200, "jacob navia" <ja***@jacob.re mcomp.fr>
wrote:

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
--
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:29:19 GMT, Leor Zolman <le**@bdsoft.co m> wrote:

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

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
--
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:29:19 GMT, Leor Zolman <le**@bdsoft.co m> wrote:

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

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

[Dan Pop]

In <r2************ *************** *****@4ax.com> Leor Zolman <le**@bdsoft.co m> writes:

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).
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de