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

[Michael E. Caloroso]

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
>>
> 
>