C and MISRA, blues... (arithmetic shifts)

Chris H wrote:
> In message <SuCdnb4TBovD9I_VnZ2dnUVZ8uadnZ2d@pipex.net>, Steve at
> fivetrees <steve@NOSPAMTAfivetrees.com> writes
>> "Richard Phillips" <raphillips@ntlworld.com> wrote in message
>> news:kukQj.59491$h65.48326@newsfe2-gui.ntli.net...
>>> * You're not supposed to use "goto".  Avoiding this when you're
>>> learning to write code is good practise, but it's very useful in a
>>> limited set of circumstances, if used properly.  I remember a
>>> manager of mine telling a work colleague once that using "goto" was
>>> bad practise, I then showed my colleague my copy of K+R which
>>> basically put him right.
>>>
>>> * You're not supposed to exit from a controlled loop prematurely.
>>
>> Avoiding "goto" means avoiding unstructured design (i.e. using only
>> only closed structures - one start, one end, any other context
>> signalled by other means than programme flow).
>
> However as with all things there are a few exceptions where got is the
> cleanest solution.  In those cases you need to deviate and be able to
> stand up in court in 3 years time with your deviation.
>
>
> Intestinally the "goto" is bad" came from a paper by Dykstra  (not
> Wilco :-) and AFAIK no one has really challenged it but just taken it
> as read. I know some people are doing some work into it to see if it
> really is that bad.
>
> I suspect the trouble will be that 90% of those who want to use goto
> are the sort of people who will write appalling code anyway and 90%
> of those who think goto should be banned would only ever use it very
> sensibly.
> So it is a self fore filling prophesy:
>
> 90% of those who want to use it should not
> 90% of those who could use it properly will not.
>
> The group who want to use it and would use it properly are now a very
> small number.

Well said!!  Agree with that 100%.

R. 

Steve at fivetrees wrote:

> "Stefan Reuther" <stefan.news@arcor.de> wrote in message
> news:futb8o.e8.1@stefan.msgid.phost.de...
> > Nils wrote:
> >> But do you do if you need them anyway? I need *lots* of them, so in
> >> despair I've just created this monster of unreadable code:
> >>
> >> int ArithmeticShiftRight (int value, unsigned int shift)
> >> {
> >      /* Not sure whether that passes your MISRA checker: */
> >      return (int) ((unsigned long long) value >> shift);
> >> }
> >
> > That aside, MISRA usually allows you to deviate from a rule if you
> > have
> > a good reason. This is to make you think about whether you really need
> > it. Arithmetic shifts would be a good thing to answer "yes" to that
> > question.
> >
> > The function could finally even look like this:
> >  int ArithmeticShiftRight (int value, unsigned int shift)
> >  {
> >  #if ((-1) >> 1) == -1
> >     return value >> shift;
> >  #else
> >  #  error Port me!
> >  #endif
> >  }
> > which would make your code portable under all practical definitions
> > known to me.
>
> I totally agree - I do exactly this as a matter of routine. I strongly
> encourage the use of macro-level platform traps which say "if this isn't
> the platform I made allowances for and assumptions about, then yell -
> don't just compile incorrectly".

I agree with the idea but be careful of the implementation.
The math executed in
#if ((-1) >> 1) == -1
is done so with the preprocessor and not the runtime
environment. They may not be the same.

I have seen two or three run time test routines written to
identify compiler features and how they work. This
would be a good place to use this type of code.
I will try to track down a url reference.

Walter..

In message <PzDQj.70642$kN5.46880@newsfe1-gui.ntli.net>, Richard 
Phillips <raphillips@ntlworld.com> writes
>Fair point.  I suppose MISRA does give a useful yardstick when measuring the
>"quality" of code.  I'll confess I hadn't looked at it from this viewpoint.
>
>One thing I will say which you've touched upon here, is that I've tightened
>up on my code quality (not that it was deliberately bad before!) because I'm
>aware that MISRA might not like something.  I tend to write code that is
>MISRA-compliant (most of the time) without even really thinking about it
>now.

This is what we were hoping for. It is a bit like Pavlovs dogs. (Bell 
rings-> get food:dogs salivate. evetualy dogs salivate when bell rings 
even if no food)

If people keep getting MISRA-C errors flanged they will eventually stop 
writing code with MISRA-C errors in it (as much as any one write bug 
free SW)

This saves time and effort and produces safer more reliable code faster.

Static analysis such as PC-Lint will have a similar effect.

BTW you should use a static analyser that checks MISRA rules not a tool 
that ONLY checks for MISRA rules. (See section 4.3)

>So I think on the whole, MISRA has perhaps been more useful than I give it
>credit for.

If we can raise the level of the masses by 1 or 2 points then that is a 
worth while goal.

>  But I stand by my original arguement though; blindly following
>the rules (as I've seen done) is NOT "advisory"!

I agree.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <gIDQj.112578$5i5.4642@newsfe6-gui.ntli.net>, Richard 
Phillips <raphillips@ntlworld.com> writes
>Steve at fivetrees wrote:
>> "Richard Phillips" <raphillips@ntlworld.com> wrote in message
>> news:kukQj.59491$h65.48326@newsfe2-gui.ntli.net...
>>> * You're not supposed to use "goto".  Avoiding this when you're
>>> learning to write code is good practise, but it's very useful in a
>>> limited set of circumstances, if used properly.  I remember a manager
>>> of mine telling a work colleague once that using "goto" was bad
>>> practise, I then showed my colleague my copy of K+R which basically
>>> put him right.
>>>
>>> * You're not supposed to exit from a controlled loop prematurely.
>>
>> Avoiding "goto" means avoiding unstructured design (i.e. using only
>> only closed structures - one start, one end, any other context
>> signalled by other means than programme flow).
>
>Sorry, I think that's just wrong.  If K+R think it's ok and include it in
>the language, I think there must be some point to it.

That is blind faith some 35 years on.   The language and SW Engineering 
have moved a long way since then.  Also  C was designed as a language 
for expert programmers.

Incidentally you do not use K&R C... There have been TWO Major revisions 
of C since K&R1

Things were changed to "improve" them but nothing was removed simply to 
keep backward compatibility even if it was not a good idea for general 
use. Some things in C are banned outright for safety critical or high 
reliability code but they are still in the base language standard.


>The one case I've encountered where it's "needed"

There will always be an exception.  Only Death and Taxes are inviolate.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Walter Banks wrote:
> Steve at fivetrees wrote:
>>"Stefan Reuther" <stefan.news@arcor.de> wrote in message
>>> #if ((-1) >> 1) == -1
>>>    return value >> shift;
>>> #else
>>> #  error Port me!
>>> #endif
>>> }
>>>which would make your code portable under all practical definitions
>>>known to me.
>>
>>I totally agree - I do exactly this as a matter of routine. I strongly
>>encourage the use of macro-level platform traps which say "if this isn't
>>the platform I made allowances for and assumptions about, then yell -
>>don't just compile incorrectly".
> 
> I agree with the idea but be careful of the implementation.
> The math executed in
> #if ((-1) >> 1) == -1
> is done so with the preprocessor and not the runtime
> environment. They may not be the same.

If I read ISO 9899:1999 correctly, they have to be the same.

6.10.1p3: "The resulting tokens compose the controlling constant
  expression which is evaluated according to the rules of 6.6, except
  that all signed integer types and all unsigned integer types act as if
  they have the same representation as, respectively, the types intmax_t
  and uintmax_t defined in the header <stdint.h>."

6.6p11: "The semantic rules for the evaluation of a constant expression
  are the same as for nonconstant expressions."

Im quite optimistic that, in year 18 after ISO C, pre-standard
preprocessors have fallen into disuse :-)


  Stefan

On Fri, 25 Apr 2008 16:34:35 +0100, Chris H <chris@phaedsys.org>
wrote:

>In message <kukQj.59491$h65.48326@newsfe2-gui.ntli.net>, Richard 
>Phillips <raphillips@ntlworld.com> writes
>>
>>This is IMO exactly how MISRA should be used.
>>I've been obeying MISRA in my coding at work for years (well, sort of),
>>while there are some things I think are very good (e.g. it makes you think
>>very carefully about casting and potential overflows, it doesn't like magic
>>numbers, etc etc), there are some things I get annoyed at, such as:
>>
>>* You're not supposed to use "goto".  Avoiding this when you're learning to
>>write code is good practise, but it's very useful in a limited set of
>>circumstances, if used properly.
>
>This is true.
>
>>I remember a manager of mine telling a
>>work colleague once that using "goto" was bad practise, I then showed my
>>colleague my copy of K+R which basically put him right.
>
>
>Maybe. IT was AFAIK Dykstra who said goto was bad and no one has 
>challenged that with a convincing strategy for using goto. Mainly 
>because the majority who do use it tend to miss use it.  So it should 
>not normally be used but...

I have only been working for more than three decades in the IT sector,
so I am youngster compared to many in this NG, but the only time I
have seen bad goto spaghetti code, was a factory management package
written in the late 1970's in COBOL. 

Of course, the situation might have been much worse in the 1960's, but
why make such fuss about gotos in this millennium ?

Paul

Walter Banks wrote:

> I agree with the idea but be careful of the implementation.
> The math executed in
> #if ((-1) >> 1) == -1
> is done so with the preprocessor and not the runtime
> environment. They may not be the same.

It's way worse than that.  Shifting negative values at runtime causes 
undefined behaviour.  I.e. even if they come out the same in the test, 
it can suddenly behave differently in the actual program, but only if 
you called gettimeofday() within 2 seconds before computing (-1)>>1. 
And you'ld have no leg to stand on if you complained about it to the 
compiler maker.  Undefined behaviour means that _all_ bets are off.

Hans-Bernhard Br�ker wrote:
> Walter Banks wrote:
>> I agree with the idea but be careful of the implementation.
>> The math executed in
>> #if ((-1) >> 1) == -1
>> is done so with the preprocessor and not the runtime
>> environment. They may not be the same.
> 
> It's way worse than that.  Shifting negative values at runtime causes
> undefined behaviour.  I.e. even if they come out the same in the test,
> it can suddenly behave differently in the actual program, but only if
> you called gettimeofday() within 2 seconds before computing (-1)>>1. And
> you'ld have no leg to stand on if you complained about it to the
> compiler maker.  Undefined behaviour means that _all_ bets are off.

'(-1) >> 1' is implementation-defined, not undefined. Implementations
that define it as 'exec("/usr/games/nethack")' are rare.

'1 >> (-1)' is undefined.


  Stefan

Hans-Bernhard Br�ker schrieb:

> It's way worse than that.  Shifting negative values at runtime causes 
> undefined behaviour.  I.e. even if they come out the same in the test, 
> it can suddenly behave differently in the actual program, but only if 
> you called gettimeofday() within 2 seconds before computing (-1)>>1. And 
> you'ld have no leg to stand on if you complained about it to the 
> compiler maker.  Undefined behaviour means that _all_ bets are off.

No - it is not undefined behaviour, it is implementation-defined 
behaviour. This is a big difference because any ISO-compliant compiler 
has to define how they handle these cases. And these behavious don't 
change just because you've called gettimeofday().

You can trust these definitions.


The GCC manual has a nice list of them:

http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/C-Implementation.html#C-Implementation

Nils

In message <4811F36B.FD35B43D@yahoo.com>, CBFalconer 
<cbfalconer@yahoo.com> writes
>Richard Phillips wrote:
>>
>... snip ...
>>
>> The problem is there is some misunderstanding here.  MISRA lists
>> it's rules as "recommended" and "required" (or something like
>> that), which makes it sound like "required" rules MUST be obeyed,
>> which doesn't appear to be the case from what I now understand.
>
>The only 'required' rules are those of the C standard.
>

Absolutely NOT.

(Which C standard? )

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/