That's why I like Lisp's generalized radix syntax - just by looking at the number, it is clear that it is "unusual" in some way and it should be closely examined. I've used the Lisp syntax for a number of DSL compilers I've written and I've never heard anybody complain that it was weird or hard to understand.
Personally I can't remember ever having a reason to use constants in bases other than 2, 10 or 16 ... but my non-decimal uses always have been limited to bit masks.
I also hate octal and the only times I ever have used it have been for setting file permissions from the shell in Unix (back when chmod took only a single octal argument).
I use hex for things like K, M, G, etc. (instead of their "marketing" versions -- which end in zeroes :> ) as well as for physical addresses.
In code, I use octal primarily for character constants. I.e., \010 is easier to recognize than a "BS" manifest constant.
An early employer used to push "split-octal" (0xFFFF -> 377377) for Z80 programming by arguing that it was easier to "hand assemble" code using octal because, for many instructions, you could synthesize an opcode by memorizing "register identifiers" and "instruction types", etc. IMO, a perfect example of misplaced priorities ("Why should I risk MISremembering an opcode when I can have the
Hmm. I like hex well enough but since I worked a lot with octal (pdp-11) many years ago, I am comfortable with it.
However, there is a nifty procedure that works by hand well, if you are lost on a deserted island somewhere and only have sand and your fingers to work conversions. (There are times, you know.) It uses octal.
Sometimes, when I convert something from hex to decimal without a calculator around, I first convert to octal and perform one of the below algorithms. Similarly, at times when converting from some decimal number into hex, I may first convert it to octal (see below) and then quickly translate that over to hex.
Anyone care to explain why the algorithms below work at all and are "symmetrical?"
CONVERSION OF DECIMAL TO OCTAL
(0) Prefix the number with "0." Be sure to include the radix point. It's an important marker.
(1) Double the value to the left side of the radix, using octal rules, move the radix point one digit rightward, and then place this doubled value underneath the current value so that the radix points align.
(2) If the moved radix point crosses over a digit that is 8 or 9, convert it to 0 or 1 and add the carry to the next leftward digit of the current value.
(3) Add octally those digits to the left of the radix and simply drop down those digits to the right, without modification.
(4) If digits remain to the right of the radix, goto 1.
CONVERSION OF OCTAL TO DECIMAL
(0) Prefix the number with "0." Be sure to include the radix point. It's an important marker.
(1) Double the value to the left side of the radix, using decimal rules, move the radix point one digit rightward, and then place this doubled value underneath the current value so that the radix points align.
(2) Subtract decimally those digits to the left of the radix and simply drop down those digits to the right, without modification.
(3) If digits remain to the right of the radix, goto 1.
Something like that is also my concern. As an example, if tasking is forbidden for safety reasons, solutions to problems that are naturally solved by using tasking, tend to become more complex and thus have a bigger potential for errors.
Which is, of course, complete nonsense.
I wasn't talking about writing the code. I was talking about reading it.
They avoid constructs that are statistically proven to fail more often than others. As I tried to say already, that doesn't mean this doesn't just open a whole new can of worms introducing a lot new possibilities of doing it wrong - just in some other way.
Vinzent.
--
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
-- Waldi Ravens
At least I'm well-conditioned enough to immediately question a construct having just "|" in a boolean context. Hence the comments.
Problem is, I don't see any evidence that MISRA does that.
We're doing C++. MISRA C++ outlaws functions that return *this or a reference parameter. That is, it outlaws all implementations of iostreams. It outlaws (use instead), which means there's no longer a well-defined way to get the declaration of POSIX 'fileno' or 'fdopen'. Of course, it also outlaws errno, to encourage code like std::FILE* fp = std::fopen("file", "rb"); if (fp == NULL) { printf("something bad happened, but I don't tell you what\n"); } (needless to say, all practical C++ers I know agree that NULL is bad style in C++.) It also outlaws strcpy, memcmp, etc., because they might be accidentally used on a wrong buffer or without a null check. By the same argument, we'd have to outlaw addition, multiplication and division as well, because they might be accidentally used on a wrong operand.
Neither of these has any specific track record for our product. The only single problem source sticking out is signed/unsigned problems, of which we had a handful: '(-20)/2U' has an unexpected result. Of course, our rule checker does not find that (gcc does, with an increadibly high false-positive rate). Other than that, most defects were algorithmic, not language problems.
Well, that's surely a plus of having to work in only one language mostly, but when you're forced to adapt your mind from Python to Perl to Ada, back to Java and then to C again, conditioning the mind for each potentially questionable construct of every one of those languages is not that easy. (Of course, not all have the same criticality level, yet conditioning the mind for slopiness in one case and strict rules in another seems even harder.)
Which part? The statistics or the failures? ;)
Maybe original MISRA wasn't intended for systems which even had I/O. ;)
Playing devil's advocate, this is a sure sign of MISRA helping you in the development, by making it harder for the "easy" bugs to creep in, leaving you only the hard ones to concentrate on. Mission accomplished. :)
And I am not trying to argue _for_ the MISRA rules here, I a just trying to point out why they exist. Again, if anybody thinks MISRA will make the code safer just by obeying the rules, they are mistaken. The human part is still the important one. We, as truly responsible coders don't need those rules, the rules are always there for the other 80% who make the silly mistakes. ;)
I remember the last talk with my boss:
B: "So what are you currently doing?" M: "Still at refactoring the $horrible_stuff, should be finished by today. One can say, I completely rewrote it by now." B: *raises eyebrows* "So it needs to be tested before?" M: *question mark in my face* "Errm, what answer do you expect now? - Yes, of course, it needs to be tested."
I am human, I did, I do and I will make errors and no f*cking rules will ever be able to change that.
Vinzent.
--
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
-- Waldi Ravens
I do less Pascal than I used to do, but I'm switching from C to C++ to Assemblers to Perl to Lisp to Javascript to Lua to Shell, that's not an issue :)
Indeed, many of the rules make much more sense if you have an engine control unit in mind, not an infotainment device with a megapixel screen and a few Gigs of flash.
How does MISRA come into play here? For the code I have statistics about, we still managed to avoid most of it :-)
Right now, I'm just seeing I have to add things, like casts for every other assignment, which makes it harder to see the forest for the tree. I'm not complaining about adding '{' for 'if', and I'm only half complaining about having to use 'int_fast16_t' instead of 'int' (which have precisely the same semantics, but the practical problem is that many C/C++ developers don't realize that), but I'm complaining about p[0] = static_cast(v & 255); p[1] = static_cast((v >> 8) & 255); which just doesn't add value, just noise.
And, in particular, I'm getting grumpy when having to change older, perfectly working and tested code, adding the potential for new bugs, just to get it through a checker which has already proven by example that it itself has bugs.
All systems MISRA is aimed at have IO... It is just that most don't have screens.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.