Using underlying bit representations of floats

[hammer1234]

Let me guess, all your programming teachers took points off for not
commenting like this?

No actually if you read any of the previous postings. MISRA C:2004
states that c90 must be used for compliant code. Therefore this is the
only way to comment. There is a specific rule that bans the use of //.

What you're doing is highly implementation dependent anyway so I'm not
going to bother to nitpick if unsigned int doesn't have the same
size/alignment as float or if unsigned int has any trap representations
but I will say that the only correct way to do the above is to
basically use:

float f = whatever;
unsigned int in;
assert(sizeof(f) == sizeof(in));
memcpy(&in, &f, sizeof(f));

or the following:

float f = whatever;
unsigned char *cp = (unsigned char*)&f;
for (size_t i = 0; i != sizeof(f); ++i) {
do_something_with(cp);
}

which is the only way guaranteed not to do anything undefined by the
standard but since you need to know how the bits are laid out anyway
and it's really annoying messing with the float bits as unsigned
char[sizeof(float)], I'd probably stick with the first one (but with
the unsigned int typedeffed as floatbits_t or something).

I am not worried about doing anything undefined by the standard as I am
creating test cases with intentional violations. Using the bit
representations of floats is a straight violations of MISRA C 2004 rule
12.12.

 

[Ian Collins]

No actually if you read any of the previous postings. MISRA C:2004
states that c90 must be used for compliant code. Therefore this is the
only way to comment. There is a specific rule that bans the use of //.

I think he was sniping at your self evident comment...

 

[Keith Thompson]

No actually if you read any of the previous postings. MISRA C:2004
states that c90 must be used for compliant code. Therefore this is the
only way to comment. There is a specific rule that bans the use of //.

The comment in question was:

] y=&aa; /* Assign y the address of aa*/

I think the complaint was that the comment merely repeats what the
code says without adding any useful information. (// comments are
discouraged in comp.lang.c anyway, because they don't survive line
wrapping.)

 

[hammer1234]

(e-mail address removed) wrote:

I think he was sniping at your self evident comment...

Haha, I c now

 

[Richard Bos]

Richard Bos a écrit :

No guarantees. This is not production code.

It would have been rather more beginner-friendly to mention that in the
first place, wouldn't it? Your post suggested that these structs _would_
work, not that they _might_ given the right amount of luck.

The underscored identifiers are easily explained: I took them from the
lcc-win32 headers, and they are part od the lcc-win32 implementation.

That is a quite good demonstration of why it is a bad idea to use such
identifiers (had they been used with an even slightly different
definition, that would've bombed on lcc-win32), and why they should not
be used in sample code on Usenet.

Probably in other machines this needs to be adjusted accordingly.

Or cannot be done reliably at all. Using an unsigned char pointer always
works.

Please be careful before teaching newbies bad habits.

Richard