MISRA Discussion Forums

Full Version: Misra C:2004 Rule 12.12
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I would like to know how to represent a Violation of rule 12.12.
It is stated in C90 that bitwise operands are required to of integer type. Therefore bitwise operators can't be used with floats to demonstrate this rule as this would be a direct violation of rule 1.1.

Is maybe pointer indirection using an unsigned char the answer?

or are there implementations that allow bitwise operators to be used with floats?

Thanks for your help!
Hammer Wrote:I would like to know how to represent a Violation of rule 12.12.
It is stated in C90 that bitwise operands are required to of integer type. Therefore bitwise operators can't be used with floats to demonstrate this rule as this would be a direct violation of rule 1.1.

Is maybe pointer indirection using an unsigned char the answer?

or are there implementations that allow bitwise operators to be used with floats?

Thanks for your help!

Knowing what the physical layout of a particular floating point system is some people have a habit of reading byes out of a floating point number . This they believe saves time and space in converting the number properly. This is the practice we wanted to stop.

Rule 1.1 is there to make people itemise the diferences betwen the compiler in use and the ISO standard. No compiler inthe embedded world rigidly complies to ISO C and it would be impossible to program pure ISO C for large parts of any embedded system.

C is not strongly typed. Just because bit wise operators work on integers does not mean you cant get them to work on floats. This is the problem.

Why are you trying to produce an example of rule 21.12 violiation? The MISRA-C panel is producing an example suite at the moment. Could you not wait for that to come out?
phaedsys Wrote:C is not strongly typed. Just because bit wise operators work on integers does not mean you cant get them to work on floats. This is the problem.

This is a bit strong. C might not be very strongly typed, but you certainly can't get away with doing bitwise ops on floats. Both C90 and C99 are quite clear on this, e.g., C99 section 6.3.10 says (of bitwise AND) that "Each of the operands shall have integral type".

A violation of 12.12 _would_ normally have to involve a cast away from the float type to an array of char, int etc. (or a union of a floating-type and an array of chars etc.) and then bitwise ops on the elements of the array. There are plenty of examples of this in, eg, Plauger's "The Standard C Library".

I do not see a situation in which you can break 12.12 without breaking other MISRA-C rules and really this is a design issue rather than a code issue. Really the rule says "if you need to look at floats in detail then use the compiler vendor provided facilities rather than rolling your own, since your own won't be portable". The validity of this statement depends on many things including: the adequacy of the vendor supplied code for your needs; the accessibility of the vendor supplied code (can you verify that it is correct!); the need for portability of the source code (do you care that your own code is target specific?); and not forgetting that not all embedded systems come with complete ANSI libraries -- you may end up having to roll your own.

Having said all that, it is sufficiently rare to have to do this kind of operation on floats that it is probably not worth getting that concerned about it.

stephen
sparker Wrote:Having said all that, it is sufficiently rare to have to do this kind of operation on floats that it is probably not worth getting that concerned about it.

stephen

Exactly. You would hope that no one would be looking inside a float at the bit represetnation hence the rule so the odd time you feel you have to do this you will need to write a deviation (that you may have to defend in court one day :-)

MISRA-C is layered. That is Rule 1 says use only ISO C.... Well no one is going to be able to do this. The idea is that you sit down and document the differences between your compiler and the standard so that you know what they are and no one is working on assumptions.

After that we have some rules that cover a wide area. You may deviate from them and one of the specific other rules under it but still conform to other specific rules inthe same area.