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

unions with long long ints and doubles?

P: n/a
I have a question regarding accessing long long ints in unions. I have
constructed a union with a double, two ints in a structure, and a long
long int. When the double is loaded with a floating-point constant, the
double is loaded correctly, and the two ints in the structure reflect
the double correctly when printed as hex values. However, when the long
long is printed as a hex value (using %016x) it prints 8 zeros then the
upper 32-bits of the double.

What am I doing wrong here? I want to be able to manipulate the double
using the long long ultimately using bit selects (that didn't work
either...).

Thanks for any help!

chris

The code for the union and the print statements and output follow.

The following union

typedef union uDblLLInts {
struct {
int iDHi;
int iDLo;
};

double dbl;

unsigned long long int llD;
} DblLLInts;

when initialized with:

DblLLInts DblA;
DblA.dbl = 1.000005;

prints this:
dbl is 1.000005e+00
int parts are 3ff000053e2d6239
long long is 000000003ff00005

for these printfs:

printf(" dbl is %e\n", DblA.dbl);
printf(" int parts are %08x%08x\n", DblA.iDHi, DblA.iDLo);
printf(" long long is %016x\n", DblA.llD);

--
************************************************** *****
Chris N. Hinds <>< www.arm.com
ARM Austin Design Center ch*********@arm.com
(512) 314-1055 (Direct)
(512) 327-9249 (Front Desk)
(512) 314-1078 (Fax)
************************************************** *****
This e-mail message is intended for the addressee(s) only and may
contain information that is the property of, and/or subject to a
confidentiality agreement between the intended recipient(s), their
organization and/or the ARM Group of Companies. If you are not
an intended recipient of this e-mail message, you should not read,
copy, forward or otherwise distribute or further disclose the
information in it; misuse of the contents of this e-mail message
may violate various laws in your state, country or jurisdiction.
If you have received this e-mail message in error, please contact
the originator of this e-mail message via e-mail and delete all
copies of this message from your computer or network, thank you.
Nov 13 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
"Chris N. Hinds" <ch*********@arm.com> wrote in message
news:bl**********@cam-news1.cambridge.arm.com...
| I have a question regarding accessing long long ints in unions. I have
| constructed a union with a double, two ints in a structure, and a long
| long int. When the double is loaded with a floating-point constant, the
| double is loaded correctly, and the two ints in the structure reflect
| the double correctly when printed as hex values. However, when the long
| long is printed as a hex value (using %016x) it prints 8 zeros then the
| upper 32-bits of the double.
....
| typedef union uDblLLInts {
| struct {
| int iDHi;
| int iDLo;
| };
Note: anonymous struct within a union are not a standard C feature.
(it's a compiler-specific extension).
.....
| prints this:
.....
| long long is 000000003ff00005
....
| for these printfs:
....
| printf(" long long is %016x\n", DblA.llD);
Note: this printf call expects an unsigned int as a parameter.
What you are triggering is undefined behavior (which happens
on your platform to drop the high 32 bits of the value).

Try:
printf(" long long is %016llx\n", DblA.llD);

(note the 'll' added to the conversion specifier)
I hope this helps,
Ivan
--
http://ivan.vecerina.com
Nov 13 '05 #2

P: n/a
In message <bl**********@cam-news1.cambridge.arm.com>
"Chris N. Hinds" <ch*********@arm.com> wrote:
I have a question regarding accessing long long ints in unions. I have
constructed a union with a double, two ints in a structure, and a long
long int. When the double is loaded with a floating-point constant, the
double is loaded correctly, and the two ints in the structure reflect
the double correctly when printed as hex values. However, when the long
long is printed as a hex value (using %016x) it prints 8 zeros then the
upper 32-bits of the double.


Your format specifier doesn't match the type - the Norcroft ARM compiler
should have warned about that. You want "%016llx".

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: +44 (0) 1223 503464
182-190 Newmarket Road Fax: +44 (0) 1223 503458
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/
Nov 13 '05 #3

P: n/a
On Tue, 30 Sep 2003 09:09:39 -0500, "Chris N. Hinds"
<ch*********@arm.com> wrote:
I have a question regarding accessing long long ints in unions. I have
constructed a union with a double, two ints in a structure, and a long
long int. When the double is loaded with a floating-point constant, the
double is loaded correctly, and the two ints in the structure reflect
the double correctly when printed as hex values. However, when the long
long is printed as a hex value (using %016x) it prints 8 zeros then the
upper 32-bits of the double.
As of C99, accessing members of a union other than the one last stored
generally results in undefined behavior. You example is not one of
the exceptions to this.

What am I doing wrong here? I want to be able to manipulate the double
using the long long ultimately using bit selects (that didn't work
either...).

Thanks for any help!

chris

The code for the union and the print statements and output follow.

The following union

typedef union uDblLLInts {
struct {
int iDHi;
int iDLo;
};

double dbl;

unsigned long long int llD;
} DblLLInts;

when initialized with:

DblLLInts DblA;
DblA.dbl = 1.000005;

prints this:
dbl is 1.000005e+00
int parts are 3ff000053e2d6239
long long is 000000003ff00005

for these printfs:

printf(" dbl is %e\n", DblA.dbl);
printf(" int parts are %08x%08x\n", DblA.iDHi, DblA.iDLo);
printf(" long long is %016x\n", DblA.llD);


<<Remove the del for email>>
Nov 13 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.