[OT] [sdiy] IN your mind, what is ....

[Forbes, William - EE - UK/Leamington]

For anybody writing C code, I would recommend the book by Les Hatton -
"Safer C - Developing Software for High-integrity and Safety-critical
Systems"
ISBN 0-07-707640-0

No safety critical system developer should ever use a non ISO/IEC compliant
complier!

Bill Forbes.

> -----Original Message-----
> From: Michael E. Caloroso [mailto:analoguediehard at att.net] 
> Sent: 04 February 2004 15:59
> Cc: synth-diy at dropmix.xs4all.nl
> Subject: Re: [OT] [sdiy] IN your mind, what is ....
> 
> 
> Yes, true as long as the C complier is ANSI C compliant.
> 
> I have encountered C compilers that goto statements can jump 
> outside of 
> a function, which is non-conformant with ANSI C.
> 
> We're getting way OT here, this isn't OOP-DIY.
> 
> MC
> 
> Forbes, William - EE - UK/Leamington wrote:
> > I would like to point out that in C at least, goto labels 
> are the only 
> > objects that have true function scope. Therefore it is not 
> possible to 
> > jump outside of a function with the standard goto.
> > 
> > Bill Forbes.
> > 
> > 
> >>-----Original Message-----
> >>From: Michael E. Caloroso [mailto:analoguediehard at att.net]
> >>Sent: 04 February 2004 15:09
> >>Cc: synth-diy at dropmix.xs4all.nl
> >>Subject: Re: [OT] [sdiy] IN your mind, what is ....
> >>
> >>
> >>
> >>>>Not a simpler solution, but it keeps the pointer stack
> >>
> >>clean which is
> >>
> >>>>a goto cannot do.
> >>>
> >>Forbes, William - EE - UK/Leamington wrote:
> >> > 'continue' and 'break' (except in a switch statement) are
> >>effectively  > goto's!  > The all cause a jump and the
> >>effects on maintainability can be just a  > severe as a goto! 
> >> > Why work round a 'goto' when a 'goto' is the most sensible
> >>thing to  > use?
> >>
> >>Don Tillman wrote:
> >> > If the operation you're doing is a naturally GOTO-like
> >>operation, what  > is so freaking horrible about implementing
> >>it with a GOTO instruction?
> >>
> >>Rainer Buchty wrote:
> >>
> >>>A goto statement does *not* affect the stackpointer. It's the
> >>>counterpart to JMP/BRA in assembly language. All it does, 
> >>
> >>is setting
> >>
> >>>the program counter. The stack pointer is influenced by
> >>
> >>gosub or, for
> >>
> >>>that matter, any function or procedure call.
> >>
> >>Therein lies the crucial difference between goto and continue/break.
> >>
> >>continue/break keep you *inside* the function.  This keeps the stack
> >>clean as you will always encounter each RET call associated 
> with its 
> >>GOSUB call.
> >>
> >>goto statements can take you *outside* the function.  Do 
> this and now
> >>you have pointers in the stack that are invalid.  This 
> fragments the 
> >>stack, raising the spectre of stack overflow and a system crash. 
> >>Framented memory is the bane of code that runs 24/7.
> >>
> >>I have done plenty of code optimization of legacy code.  Fragmented
> >>memory is one of the worse offenders and is a topic that too few 
> >>developers are aware of.  Removing fragmented memory can 
> extend code 
> >>MTBF from a few hours to weeks.
> >>
> >>Yes they may compile as JMP/BRA statements but it is the
> >>implementation 
> >>that is the difference.
> >>
> >>WRT code reliability, that's a clearer way of doing it.  The
> >>political 
> >>correctiveness of eliminating goto's is irrelevant when the target 
> >>application is critical like medical monitoring apparatus or 
> >>aerospace 
> >>controls.  If I ever set foot on a plane that contains some of my 
> >>design, you better believe I went the extra mile to confirm 
> >>reliability 
> >>as the last place to encounter stack overflow/system crash is at 
> >>30,000ft above ground.  That's what is so freaking horrible 
> >>about a goto 
> >>statement.
> >>
> >>MC
> >>
> > 
> > 
> 
>