By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,933 Members | 1,264 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,933 IT Pros & Developers. It's quick & easy.

int64 from int 32

P: n/a
Hi,
For some reason the below code doesnt produce results as i expect.

#include<stdio.h>

int main()
{

int hi=0xff;
int low=0xee;
long long big ;
big = ((long long) hi ) << 32 | low;

printf("%16x \n ",big);

}

I am lost trying to figure out the mistake i am making.Can you help me
out.Is it compiler dependent?

Deepak
Nov 12 '08 #1
Share this Question
Share on Google+
22 Replies


P: n/a
Peerless <pe*************@gmail.comwrites:
Hi,
For some reason the below code doesnt produce results as i expect.

#include<stdio.h>

int main()
{

int hi=0xff;
int low=0xee;
long long big ;
big = ((long long) hi ) << 32 | low;

printf("%16x \n ",big);

}

I am lost trying to figure out the mistake i am making.Can you help me
out.Is it compiler dependent?
The %x specifier for printf expects an unsigned argument, not a long
long. Using %llx will use an unsigned long long. So you might want

unsigned long long big;
big = ((unsigned long long)hi) << 32 | low;
printf("%16llx\n", big);

This conforms to the C99 standard, by the way, so it shouldn't be
compiler dependent.

Nov 12 '08 #2

P: n/a


Peerless wrote:
Hi,
For some reason the below code doesnt produce results as i expect.

#include<stdio.h>

int main()
{

int hi=0xff;
int low=0xee;
long long big ;
big = ((long long) hi ) << 32 | low;

printf("%16x \n ",big);

}

I am lost trying to figure out the mistake i am making.Can you help me
out.Is it compiler dependent?
Support for 'long long' is compiler dependent, because not all
compilers conform to the C99 standard in that regard yet. However, if
that had been your problem, your code would never have compiled.

I strongly recommend using unsigned types whenever you are performing
shifts or bit-masking operations. However, for the particular values
involved in your program, that's not a problem.

What is a problem is that 'big' is a "long long", and you're using
%16x as your format code, which requires an "unsigned int" argument.
After changing everything to an unsigned type, you should use
"%16llx", which expects an "unsigned long long" argument.
Nov 12 '08 #3

P: n/a
Peerless <pe*************@gmail.comwrites:
For some reason the below code doesnt produce results as i expect.

#include<stdio.h>

int main()
{

int hi=0xff;
int low=0xee;
long long big ;
big = ((long long) hi ) << 32 | low;

printf("%16x \n ",big);

}

I am lost trying to figure out the mistake i am making.Can you help me
out.Is it compiler dependent?
"%16x" expects an argument of type unsigned int. You're giving it an
argument of type long long. Use "%16llx". (It's not certain that
your runtime library will support this.)

Actually, I'd probably use "%016llx" to get the leading zeros.

Also, why do you have spaces before and after the "\n"?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
Nov 12 '08 #4

P: n/a
Nate Eldredge <na**@vulcan.lanwrites:
[...]
The %x specifier for printf expects an unsigned argument, not a long
long. Using %llx will use an unsigned long long. So you might want

unsigned long long big;
big = ((unsigned long long)hi) << 32 | low;
printf("%16llx\n", big);

This conforms to the C99 standard, by the way, so it shouldn't be
compiler dependent.
Um, are you suggesting that all compilers conform to the C99 standard?

Quibble: It's the runtime library, not the compiler, that implements
printf and the "%llx" format. Both the library and the compiler are
part of the implementation.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
Nov 12 '08 #5

P: n/a
Keith Thompson <ks...@mib.orgwrote:
Nate Eldredge <n...@vulcan.lanwrites:
...
unsigned long long big;
big = ((unsigned long long)hi) << 32 | low;
printf("%16llx\n", big);

This conforms to the C99 standard, by the way, so
it shouldn't be compiler dependent. *

Um, are you suggesting that all compilers conform to
the C99 standard?

Quibble: It's the runtime library, not the compiler,
that implements printf and the "%llx" format. *Both
the library and the compiler are part of the
implementation.
Do you know of any packaged C90 implementations that
support long long but don't support ll? It's been a
well over a decade since I've seen a C90 implementation
use L as the length specifier for long long.

--
Peter
Nov 12 '08 #6

P: n/a
Peter Nilsson <ai***@acay.com.auwrites:
Keith Thompson <ks...@mib.orgwrote:
>Nate Eldredge <n...@vulcan.lanwrites:
...
unsigned long long big;
big = ((unsigned long long)hi) << 32 | low;
printf("%16llx\n", big);

This conforms to the C99 standard, by the way, so
it shouldn't be compiler dependent. *

Um, are you suggesting that all compilers conform to
the C99 standard?

Quibble: It's the runtime library, not the compiler,
that implements printf and the "%llx" format. *Both
the library and the compiler are part of the
implementation.

Do you know of any packaged C90 implementations that
support long long but don't support ll? It's been a
well over a decade since I've seen a C90 implementation
use L as the length specifier for long long.
Packaged? No. But gcc, for example, is just a compiler; it isn't
bundled with a runtime library. It uses whatever C runtime library is
available on the platform. *If* there are still runtime libraries
that doesn't support "%llx" (perhaps because the don't support long
long at all), and if gcc is available on such sytems, then there are C
implementations that support long long but not "%llx".

I'm sure there have been such systems in the past. I couldn't tell
you which systems they are, and I don't know whether they're still in
sufficiently widespread use to be a significant concern.

gcc may not be the only example of this.

Bottom line: Check this before depending on it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
Nov 12 '08 #7

P: n/a
Peerless wrote:
Hi,
For some reason the below code doesnt produce results as i expect.

#include<stdio.h>

int main()
{

int hi=0xff;
int low=0xee;
long long big ;
big = ((long long) hi ) << 32 | low;

printf("%16x \n ",big);

}

I am lost trying to figure out the mistake i am making.Can you help me
out.Is it compiler dependent?

Deepak
Using the lcc-win compiler I obtain:
d:\lcc\mc74\test>lc tll.c
Warning tll.c: 11 printf argument mismatch for format x. Expected int
got long long
0 errors, 1 warning

It helps to get a compiler with good warnings.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Nov 12 '08 #8

P: n/a
On Wed, 12 Nov 2008 23:12:18 +0100,
jacob navia <ja***@nospam.comwrote:
Peerless wrote:
>Hi,
For some reason the below code doesnt produce results as i expect.

#include<stdio.h>

int main()
{

int hi=0xff;
int low=0xee;
long long big ;
big = ((long long) hi ) << 32 | low;

printf("%16x \n ",big);

}

I am lost trying to figure out the mistake i am making.Can you help me
out.Is it compiler dependent?

Deepak

Using the lcc-win compiler I obtain:
d:\lcc\mc74\test>lc tll.c
Warning tll.c: 11 printf argument mismatch for format x. Expected int
got long long
Isn't the compiler supposed to expect an unsigned int here, instead of
an int?
0 errors, 1 warning

It helps to get a compiler with good warnings.
FWIW, gcc also warns for this, but it claims to be expecting an
unsigned int.

Martien
--
|
Martien Verbruggen | Failure is not an option. It comes bundled
| with your Microsoft product.
|
Nov 12 '08 #9

P: n/a
Peerless wrote:
Hi,
For some reason the below code doesnt produce results as i expect.

#include<stdio.h>

int main()
{

int hi=0xff;
int low=0xee;
long long big ;
big = ((long long) hi ) << 32 | low;

printf("%16x \n ",big);

}

I am lost trying to figure out the mistake i am making.Can you help me
out.Is it compiler dependent?

Deepak
What did you expect? Try this.

#include <stdio.h>

int main(void)
{
int hi = 0xff;
int low = 0xee;
long long big;
big = ((long long)hi) << 32 | low;
printf("%016Lx\n", big);
return 0;
}

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 12 '08 #10

P: n/a
Martien Verbruggen <mg**@heliotrope.com.auwrites:
On Wed, 12 Nov 2008 23:12:18 +0100,
jacob navia <ja***@nospam.comwrote:
>Peerless wrote:
[...]
>> long long big ;
[...]
>> printf("%16x \n ",big);
[...]
>>
Using the lcc-win compiler I obtain:
d:\lcc\mc74\test>lc tll.c
Warning tll.c: 11 printf argument mismatch for format x. Expected int
got long long

Isn't the compiler supposed to expect an unsigned int here, instead of
an int?
Yes. More precisely, printf expects an unsigned int; the compiler
isn't required to warn you about it, but it chooses to do so. (To be
clear, that's a good thing.)

Out of curiosity, what does lcc-win do with this?

#include <stdio.h>
int main(void)
{
int i = 0;
unsigned int ui = 0;
long l = 0;
unsigned long ul = 0;
printf("i = %x\n", i);
printf("ui = %x\n", ui); /* ok */
printf("l = %x\n", l);
printf("ul = %x\n", ul);
return 0;
}

Warnings would be appropriate for the first, third, and fourth
printfs, though it could be argued that the first is ok. The third
and fourth are certainly a problem if int and long are of different
sizes; even if they're the same size for a given implementation, IMHO
a warning is sill appropriate.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
Nov 12 '08 #11

P: n/a
Joe Wright <jo********@comcast.netwrites:
[...]
What did you expect? Try this.

#include <stdio.h>

int main(void)
{
int hi = 0xff;
int low = 0xee;
long long big;
big = ((long long)hi) << 32 | low;
printf("%016Lx\n", big);
return 0;
}
The 'L' length modified applies to long double. The format for
unsigned long long in hex is "%llx".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
Nov 12 '08 #12

P: n/a
Keith Thompson wrote:
Joe Wright <jo********@comcast.netwrites:
[...]
>What did you expect? Try this.

#include <stdio.h>

int main(void)
{
int hi = 0xff;
int low = 0xee;
long long big;
big = ((long long)hi) << 32 | low;
printf("%016Lx\n", big);
return 0;
}

The 'L' length modified applies to long double. The format for
unsigned long long in hex is "%llx".
My implementation gives me a choice of L or ll.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 12 '08 #13

P: n/a
Joe Wright <jo********@comcast.netwrites:
Keith Thompson wrote:
>Joe Wright <jo********@comcast.netwrites:
[...]
>>What did you expect? Try this.

#include <stdio.h>

int main(void)
{
int hi = 0xff;
int low = 0xee;
long long big;
big = ((long long)hi) << 32 | low;
printf("%016Lx\n", big);
return 0;
}
The 'L' length modified applies to long double. The format for
unsigned long long in hex is "%llx".
My implementation gives me a choice of L or ll.
That's a legal extension. printf("%016Lx\n", big) invokes undefined
behavior; if your implementation chooses to treat it as equivalent to
printf("%016llx\n", big), it's entitled to do so.

But unless you're stuck with non-conforming implementation that
supports "L" but not "ll", there's no reason to use "L".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
Nov 13 '08 #14

P: n/a
Keith Thompson wrote:
Joe Wright <jo********@comcast.netwrites:
>Keith Thompson wrote:
>>Joe Wright <jo********@comcast.netwrites:
[...]
What did you expect? Try this.

#include <stdio.h>

int main(void)
{
int hi = 0xff;
int low = 0xee;
long long big;
big = ((long long)hi) << 32 | low;
printf("%016Lx\n", big);
return 0;
}
The 'L' length modified applies to long double. The format for
unsigned long long in hex is "%llx".
My implementation gives me a choice of L or ll.

That's a legal extension. printf("%016Lx\n", big) invokes undefined
behavior; if your implementation chooses to treat it as equivalent to
printf("%016llx\n", big), it's entitled to do so.

But unless you're stuck with non-conforming implementation that
supports "L" but not "ll", there's no reason to use "L".
Agreed.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 13 '08 #15

P: n/a
On Nov 13, 1:31*am, Keith Thompson <ks...@mib.orgwrote:
Peerless <peerlessdeep...@gmail.comwrites:
For some reason the below code doesnt produce results as i expect.
#include<stdio.h>
int main()
{
* * * * int hi=0xff;
* * * * int low=0xee;
* * * * long long big ;
* * * * big = ((long long) hi ) << 32 | low;
* * * * printf("%16x \n ",big);
}
I am lost trying to figure out the mistake i am making.Can you help me
out.Is it compiler dependent?

"%16x" expects an argument of type unsigned int. *You're giving it an
argument of type long long. *Use "%16llx". *(It's not certain that
your runtime library will support this.)

Actually, I'd probably use "%016llx" to get the leading zeros.
Thanks. How does the compiler implement integers which are greater
than the word length of the cpu? I am trying to understand how bit
shifts greater for long long are achieved in a 32 bit machine. Not
sure whether this is the right place to ask,if it doesnt please let me
know where I can post this question.

Deepak.P

Nov 13 '08 #16

P: n/a
On Nov 13, 6:59*am, Joe Wright <joewwri...@comcast.netwrote:
Keith Thompson wrote:
Joe Wright <joewwri...@comcast.netwrites:
Keith Thompson wrote:
Joe Wright <joewwri...@comcast.netwrites:
[...]
What did you expect? Try this.
>>#include <stdio.h>
>>int main(void)
{
* *int hi = 0xff;
* *int low = 0xee;
* *long long big;
* *big = ((long long)hi) << 32 | low;
* *printf("%016Lx\n", big);
* *return 0;
}
The 'L' length modified applies to long double. *The format for
unsigned long long in hex is "%llx".
My implementation gives me a choice of L or ll.
That's a legal extension. *printf("%016Lx\n", big) invokes undefined
behavior; if your implementation chooses to treat it as equivalent to
printf("%016llx\n", big), it's entitled to do so.
But unless you're stuck with non-conforming implementation that
supports "L" but not "ll", there's no reason to use "L".

Agreed.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
* * * * * * * * * * *--- Albert Einstein ---
Nov 13 '08 #17

P: n/a
Peerless wrote:
>
Thanks. How does the compiler implement integers which are greater
than the word length of the cpu? I am trying to understand how bit
shifts greater for long long are achieved in a 32 bit machine. Not
sure whether this is the right place to ask,if it doesnt please let me
know where I can post this question.
Look at the generated code, each compiler will have its own ways
depending on the platform.

--
Ian Collins
Nov 13 '08 #18

P: n/a
Keith Thompson wrote, On 12/11/08 21:16:
Peter Nilsson <ai***@acay.com.auwrites:
>Keith Thompson <ks...@mib.orgwrote:
>>Nate Eldredge <n...@vulcan.lanwrites:
...
unsigned long long big;
big = ((unsigned long long)hi) << 32 | low;
printf("%16llx\n", big);

This conforms to the C99 standard, by the way, so
it shouldn't be compiler dependent.
Um, are you suggesting that all compilers conform to
the C99 standard?

Quibble: It's the runtime library, not the compiler,
that implements printf and the "%llx" format. Both
the library and the compiler are part of the
implementation.
Do you know of any packaged C90 implementations that
support long long but don't support ll? It's been a
well over a decade since I've seen a C90 implementation
use L as the length specifier for long long.

Packaged? No. But gcc, for example, is just a compiler; it isn't
bundled with a runtime library. It uses whatever C runtime library is
available on the platform. *If* there are still runtime libraries
that doesn't support "%llx" (perhaps because the don't support long
long at all), and if gcc is available on such sytems, then there are C
implementations that support long long but not "%llx".
I believe that the library from MS is one such, and MinGW uses that
library. Some people consider MinGW to be a packaged solution (it comes
with more than just a compiler) even though it does not include its own
library.
I'm sure there have been such systems in the past. I couldn't tell
you which systems they are, and I don't know whether they're still in
sufficiently widespread use to be a significant concern.
MinGW, sufficiently recent ports of gcc to SCO 5.0.5 (I know of people
still using this version of SCO), I suspect there may be others. Howver,
as you say, they may not be of interest to the OP.
gcc may not be the only example of this.

Bottom line: Check this before depending on it.
Agreed.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/
Nov 13 '08 #19

P: n/a
Peter Nilsson wrote:
Keith Thompson <ks...@mib.orgwrote:
>Nate Eldredge <n...@vulcan.lanwrites:
>>...
unsigned long long big;
big = ((unsigned long long)hi) << 32 | low;
printf("%16llx\n", big);

This conforms to the C99 standard, by the way, so
it shouldn't be compiler dependent.

Um, are you suggesting that all compilers conform to
the C99 standard?

Quibble: It's the runtime library, not the compiler,
that implements printf and the "%llx" format. Both
the library and the compiler are part of the
implementation.

Do you know of any packaged C90 implementations that
support long long but don't support ll? It's been a
well over a decade since I've seen a C90 implementation
use L as the length specifier for long long.
Isn't L the lenth specifier for long double?

BTW: I do know one c89 implementation that supported long long, but not
unsigned long long, bizarr, eh?

Bye, Jojo
Nov 13 '08 #20

P: n/a
Martien Verbruggen wrote:
On Wed, 12 Nov 2008 23:12:18 +0100,
jacob navia <ja***@nospam.comwrote:
>Peerless wrote:
>>Hi,
For some reason the below code doesnt produce results as i expect.

#include<stdio.h>

int main()
{

int hi=0xff;
int low=0xee;
long long big ;
big = ((long long) hi ) << 32 | low;

printf("%16x \n ",big);

}

I am lost trying to figure out the mistake i am making.Can you help me
out.Is it compiler dependent?

Deepak
Using the lcc-win compiler I obtain:
d:\lcc\mc74\test>lc tll.c
Warning tll.c: 11 printf argument mismatch for format x. Expected int
got long long

Isn't the compiler supposed to expect an unsigned int here, instead of
an int?
>0 errors, 1 warning

It helps to get a compiler with good warnings.

FWIW, gcc also warns for this, but it claims to be expecting an
unsigned int.

Martien

True. I have fixed the warning message text. Now it will say it expects
unsigned when using formats o, u, x or X.

Thanks for your remark.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Nov 13 '08 #21

P: n/a
Peerless wrote:
>
.... snip ...
>
Thanks. How does the compiler implement integers which are greater
than the word length of the cpu? I am trying to understand how bit
shifts greater for long long are achieved in a 32 bit machine. Not
sure whether this is the right place to ask,if it doesnt please
let me know where I can post this question.
The method varies. For example, the system may provide a
subroutine to perform it, and call that as needed. Or it may
generate the machine code to operate on a sequence of words.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Nov 13 '08 #22

P: n/a
CBFalconer <cb********@yahoo.comwrites:
Peerless wrote:
>>
... snip ...
>>
Thanks. How does the compiler implement integers which are greater
than the word length of the cpu? I am trying to understand how bit
shifts greater for long long are achieved in a 32 bit machine. Not
sure whether this is the right place to ask,if it doesnt please
let me know where I can post this question.

The method varies. For example, the system may provide a
subroutine to perform it, and call that as needed. Or it may
generate the machine code to operate on a sequence of words.
Or the CPU might provide direct support for operations on quantities
bigger than the "word" size. (This gets into questions about what a
"word" is; I don't think there's any universally accepted definition.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
Nov 13 '08 #23

This discussion thread is closed

Replies have been disabled for this discussion.