'splitting' a double

[zxcv]

Hello

Id like to take a double and split it into its 32 bit high and low bits. Id like to be left with 2 pointers to both 'halves'.

Heres what I'm thinking:

void split(double x) {
	unsigned int *low_bits  = (unsigned int *)&x;
        unsigned int *high_bits = (unsigned int *)(&x + sizeof(int));
 
	printf("low = 0x%0000008x\n", *low_bits);
	printf("high = 0x%0000008x\n", *high_bits);
}

So it was called with 0xFFFFFFFF00000000 Id expect to see 0x00000000 and 0xFFFFFFFF printed(or maybe I have it backwards), but I dont. I'm not sure why.

Thanks

(Yeah, this is kind of cheesy and probably a bad idea in general but I need something like this for my computer architecture class. Were working with floating points and we can only use ints. This will make life much easier)

[vart]

Your problem is the wrong using of pointer arithmetics

+delta moves pointer not to delta bytes but to delta units, each unit size depends on the pointre type

So you can use high_bits = low_bits +1;
Or if you prefer your approach - cast &x to unsinged char before adding sizeof(int)

[matsp]

Or something like:

        unsigned int *high_bits = ((unsigned int *)(&x)) + 1;

--
Mats

[cwr]

Or something like:

        unsigned int *high_bits = ((unsigned int *)(&x)) + 1;

This is undefined behaviour, as is the original poster's code. You may only use a character pointer. If you have the ISO/IEC 9899:1999 standard handy, see section 6.3.2.3 paragraph 7.

The following, for example, is well defined:

void split(double x)
{
    unsigned char *y = (unsigned char *)&x;
    int i;
    for (i = 0; i < sizeof(double); i++)
        printf("%02x", y[i]);
    puts("");
}

[matsp]

Correct, but it's only undefined if a double is not aligned to the same as (or a multiple of) "unsigned int", and whilst I'm sure there are machines where such a construction may be the case (someone implementing for example 56 or 80 bit "double" would fall into this category), it is not a common occurrence.

Does anyone here actually know of (and are actually using, as opposed to knowing of the existence) a machine where this is the case?

--
Mats

[Dino]

Having doubles not on proper boundaries can happen on any machine when reading binary records from a file that were written as such.

[matsp]

Having doubles not on proper boundaries can happen on any machine when reading binary records from a file that were written as such.

Sure, and then you probably would get integers on unaligned boundaries too - in which case you need to take care of it.

In the above case, the value is in a parameter to a function, so the address is not dictated by some (unaligned) struct.

[By the way, if it's strictly necessary for a double to align to a certain boundary, then constructing structs that have such fields unaligned will be "unusable" for any meaningfull purpose].

In x86, the fields can have any alignment they like, and both integers and doubles will work just fine with that - it will be at somewhat reduced performance, but it will WORK. Other processor architectures may or may not accept data that isn't properly aligned - and this is the main point about it being undefined - the C standard does not want to define what happens if you access a pointer to integer which is not aligned to a "integer-compatible boundary" - it may work just fine, or it may cause an exception in the processor, which leads to the application crashing - or something else may happen [e.g. the data at the nearest aligned address gets used ].

--
Mats

[iMalc]

Hello

Id like to take a double and split it into its 32 bit high and low bits. Id like to be left with 2 pointers to both 'halves'.

So it was called with 0xFFFFFFFF00000000 Id expect to see 0x00000000 and 0xFFFFFFFF printed(or maybe I have it backwards), but I dont. I'm not sure why.

You shouldn't expect to see anything like that. Doubles are very different from integer types in memory. If you expect to be able to represent 0 thru 16F's in a double then how do you expect to store 0.1?