raw byte representation of unsigned long long?

[wenmang]

Hi,
I encountered a problem involving storage of unsigned long long. The
requirement of incoming data field is an unsigned 64-bit integer, but
on our system, due to lack of support of 64-bit integer from Oralce
pro-C(it only supports 32-bit integer). We have to find a way to get
around it. I am wondering whether there is other way to store big int
in kind of 8-byte raw data and later convert it to 64-bit integer. Is
the raw data has to be stored as C-string? Certainly, we can use
double, but I like to know whether we have other option or not. thx

[Ulrich Eckhardt]

we*****@yahoo.com wrote:

I encountered a problem involving storage of unsigned long long. The
requirement of incoming data field is an unsigned 64-bit integer, but
on our system, due to lack of support of 64-bit integer from Oralce
pro-C(it only supports 32-bit integer).

Switch compilers.

We have to find a way to get around it. I am wondering whether there
is other way to store big int in kind of 8-byte raw data [..]

Sure, just store it in eight bytes (uint8_t or unsigned char).

[..]and later convert it to 64-bit integer.

How so, if there is no 64 bit integer type?

I'm not sure where your problem is, but remember that after all any object
is stored as a sequence of bytes. The much more interesting part is what
you want to do with the integer. If you only need to store it or move it
around, just use a struct containing an array of eight octets or
equivalent. If you need to do arithmetic with it, you might consider
splitting it into two parts of 32 bit each.

Is the raw data has to be stored as C-string? Certainly, we can use
double, but I like to know whether we have other option or not.

Why would you store it as C string? It is not text and it surely is not
terminated by a trailing NUL.

Further, I don't think double can be used to store 64 bit integral numbers
(at least not without discarding some digits), but long double might
be. "might be" because it is possible that long double is no bigger than
double.

Uli

[wenmang]

Our systemm does support uint64_t, the problem comes from Oracle Pro-C
code which doesn't support 64-bit integer. I can do following:
typedef unsigned char octet;
octet bigNum[sizeof(uint64_t)];
uint64_t myBigNum = 1000;
memcpy(&bigNum, &myBigNum, sizeof(myBigNum));
the corresponding field at Oracle DB table is defined as a number, the
only question left is whether DB can enterpret 8 raw bytes as DB
number and store it correctly?
So, instead of using a uint64_t we can use octet[] instead if it works.
Ulrich Eckhardt wrote:

we*****@yahoo.com wrote:

I encountered a problem involving storage of unsigned long long. The
requirement of incoming data field is an unsigned 64-bit integer, but
on our system, due to lack of support of 64-bit integer from Oralce
pro-C(it only supports 32-bit integer).

Switch compilers.

We have to find a way to get around it. I am wondering whether there
is other way to store big int in kind of 8-byte raw data [..]

Sure, just store it in eight bytes (uint8_t or unsigned char).

[..]and later convert it to 64-bit integer.

How so, if there is no 64 bit integer type?

I'm not sure where your problem is, but remember that after all any object
is stored as a sequence of bytes. The much more interesting part is what
you want to do with the integer. If you only need to store it or move it
around, just use a struct containing an array of eight octets or
equivalent. If you need to do arithmetic with it, you might consider
splitting it into two parts of 32 bit each.

Is the raw data has to be stored as C-string? Certainly, we can use
double, but I like to know whether we have other option or not.

Why would you store it as C string? It is not text and it surely is not
terminated by a trailing NUL.

Further, I don't think double can be used to store 64 bit integral numbers
(at least not without discarding some digits), but long double might
be. "might be" because it is possible that long double is no bigger than
double.

Uli

[Keith Thompson]

"we*****@yahoo.com" <we*****@yahoo.comwrites:

Our systemm does support uint64_t, the problem comes from Oracle Pro-C
code which doesn't support 64-bit integer. I can do following:
typedef unsigned char octet;
octet bigNum[sizeof(uint64_t)];
uint64_t myBigNum = 1000;
memcpy(&bigNum, &myBigNum, sizeof(myBigNum));
the corresponding field at Oracle DB table is defined as a number, the
only question left is whether DB can enterpret 8 raw bytes as DB
number and store it correctly?

[...]

If that's the only question left, then you're asking it in the wrong
place.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.