Any idea how do i print the value contained in this variable using printf ?
There is no supporting type ( as in %type ) that i can use in printf to
print vale of a 64 bit variable ?
We are using this var to store timestamp, which the std says shud be 64 bits
long, hence the prob.
Actually in VC++ u have a microsoft specific extension type called I64,
which can be used to print 64 bit value, but such a thing is not present in
VxWorks.
any pointers from people who have already experienced such a prob on VxWorks
?
Thanx,
deepak
The only way I've seen it doen is by splitting it into two 32-bit
vars, and putting them side-by-side, at least with the gnu
compiler and assoc. libs.
Speaking only for myself,
Joe Durusau
I have one more basic doubt here, hoep u can clarify me on this.
In C std, the std says that operands of the bitwise operations are
promoted to the integer data type, and the result ( intermediate ) is
also stored in an interger data type. SO when i use bitwise shift
operators with unsigned long long, which is of bigger size than the
integer data type, how does the result ( intermediate ) get stored ?
WHat actually happens inside ?
deepak
If I recall correctly, the standard also says that intermediate results are
promoted to the largest integer present in the expression, so whenever
a long long is present, the intermediate will be too 64-bit.
Leonid Rosenboim wrote:
If I were you, I wouldn't put too much faith in the standard, esp.
if you are using the gnu compiler that wrs ships. It is very old,
and may not support long long at all. You can find out what it's
doing by looking at the assembler output.
> In VxWorks, i have a variable of type unsigned long long.
> This basically means that the size of this var is 8 bytes ( 64 bits )
>
> Any idea how do i print the value contained in this variable using printf ?
>
> There is no supporting type ( as in %type ) that i can use in printf to
> print vale of a 64 bit variable ?
The format that you're supposed to use is "%lld" for a 'signed long long'
and "%llu" for an 'unsigned long long'. However, if I remember correctly,
the libraries that WindRiver ships with the egcs compiler in 5.4 do not
recognize this. Consequently, you have to write your own function to do
it.
Also, the topic of bit shifts on a long long came up in this thread. The
documentation that ships with 5.4 says that bit shitfs on a long long may
or may not be supported on any particular platform. This means that a
bit shift on a 64 bit long long may well discard the most significant 32
bits. Use at your own risk.
Keith
--
"Once something has gone horribly wrong..."
"...it just gets horribler and horribler."
"Then, it's a matter of finding the original horriblism."
-- from a conversation on debugging problems in a linked list
[snip]
> If I were you, I wouldn't put too much faith in the standard, esp.
> if you are using the gnu compiler that wrs ships. It is very old,
> and may not support long long at all. You can find out what it's
> doing by looking at the assembler output.
>
> Speaking only for myself,
>
> Joe Durusau
Joe, I have used the WRS GNU compiler with long long quite extensively
during the development of DosFs2, and the core filesystem in DosFs2
still uses 64-bit integer math fairly succesfully.
There is a know issue with long long on some PPC processors that
use FP regs (there is a gcc patch for this), and there is this well know
issue that WRS stdio lacks long long support so people have to write
their own routines to convert log long to strings for printing.
By the way, there is a 64-bit int to string function inside dosFs2,
but it is not exposed.
-- hth
-----------------------------------------------------------------------
Leonid Rosenboim Visit:
http://gamla.org.il/english/index.htm
Consultant Email: my first name at consultant dot com
logMsg("64 Bit Value = 0x%08X%08X \n", (uint32)(LongLongValue>>32),
(uint32)(LongLongValue&0x0ffffffff));
Dan