code repeat

[gatoulisss]

hello guys!
is there any way of repeat this code line without writing them?

           delay_ms(5000);
           if (porta.f0==0) {goto start;}

because if i write it the programm crashes i dont know why... maybe the delay times are too big

[SL4P]

Maybe more useful to post the whole code snippet that crashes.
(Not necessarily your whole program!)

A couple of pointers -
You could use a while () loop; or do-while();
or even a simple for() loop with well placed break or continue statements.

But generally in C, a goto statement is frowned upon as it doesn't respect the internal states of the hardware unless the compiler is being very kind to you.  It's really easy to have unexplained crashes if the stack and PC get locked up.

[Nerull]

There's nothing inherently wrong with goto, its the bad habits it can create that cause problems. A goto-loop and a while loop, properly written, are going to produce almost identical output from the compiler. Its just an unconditional jmp, which I assure you your compiler is littering all over your nice "goto-less" code. C is a language which provides a million ways to smash your stack or crash your program. Used carefully, goto isn't a particularly risky one. There's a classic linux-kernel thread where a guy gets flamed to hell and back for trying to patch gotos out of the linux kernel code, because his solutions made everything worse.

Its much better to understand why you should or shouldn't use various language constructions in different situations, than following dogma without understanding why.

This tiny snippet of code, however, is like someone holding up a single wire and asking what's wrong with their circuit. We can't help you from that tiny little piece.

[SL4P]

...A goto-loop and a while loop, properly written, are going to produce almost identical output from the compiler. ...

Goto (contained within a loop) is quite different from goto 'start' or some other address outside the loop.

[elgonzo]

But generally in C, a goto statement is frowned upon as it doesn't respect the internal states of the hardware unless the compiler is being very kind to you.  It's really easy to have unexplained crashes if the stack and PC get locked up.

What compiler are you talking about?
Any C compiler worth the name handles goto just fine and does not produce buggy binaries.
The goto statement is usually frowned upon because it leads to messy source code (aka spaghetti).
Messy source code is a maintenance issue and can lead to writing buggy source code. (But then again, one can write buggy source code also without using goto...)

[SL4P]

True - I should have added the spaghetti reference as well, but assumed that was a given.

Low-end / freebie embedded compilers have been known to code more literally than some others... and if goto jumps out of a loop structure occurs during an interrupt or other non-synchronous events - then all bets are off.

[helius]

if your compiler is buggy enough to allow goto across functions, you are definitely going to crash at some point.
but without shit compilers, the danger of goto is not from "jumping out of a loop": that is exactly what a break statement would do.
the danger is if your code jumps into a block, then the block's variables can contain garbage if you did not run their initializers.

Code: [Select]

if (porta.f0==0) {goto start;}
...
do {
    struct huge_thing huge1 = initialize_ht();
    start:
    charge_lazer(&huge1,0);
....
} while (1)

[SL4P]

Very true - jumping in is an absolute no-no!

break is not goto in any context.

Being that break is a fundamental member of the for/do/while construct - I would expect it to handle popping the stack and correcting any hanging pointers as part of that integrity.

[helius]

No, in C, break and continue are pretty much handled as gotos. their advantages are that the intent is clearer, and the locations to jump to are more restricted (in a way those are same advantage). Stack management is not something the user has access to: C implementations aren't required to even have a stack, but if they do they must handle it whatever the user writes. And dangling pointers aren't ever corrected, the user is responsible for tracking his pointers.

when you write an iteration statement, the compiler creates implicit labels for where to transfer control from a break or continue. this control transfer happens just like a goto to a named label.

for (x; y; z) { statements... _continue:; } _break:;

the same problem with uninitialized variables happens with switch statements too, because they are implemented just like goto:

Code: [Select]

int flag=1;
switch (flag) {
    default:
    struct hairy hs = {1, 2, 3, 4};
    case 1:
    operate(hs.b);
}
You can see that when you use switch, you are always "jumping in" to a compound statement, much as if you used goto to a label within. It is possible to use these features safely, it just presents more pitfalls and the code is brittle.

[Mechatrommer]

please stop goto debate and waste unecessary time. go look at assembly code, everything is a goto hell of a noodles. if, break, continue, switch, end of "for" brace you name it. simply put, if you know how to use it then use it, if not then dont. what confuse me is why the OP want to "repeat" a code that "crashed". as if he want to repeatedly crash his program.

[Rigby]

goto is fine if you know what you're doing and you're comfortable with it, and you're the only developer that's ever going to work with that code.

there are better ways to structure code in higher level languages.

I don't know anything about assembly so I cant' speak to that.  I can only say that gotos in higher level languages can do very odd things if you're not fully aware of how they jump around in your language.  I wouldn't use them at all, so I don't.  There are more legible ways to get what you want done, done.

I'd like to see the rest of the code that gatoulisss is having an issue with before I give any specific advice.

[Paul Price]

There is nothing wrong with the code as it is presented..unless this code is inside an interrupt service routine.

If it is not, then there is something else screwy, it is not this code that is causing the crash.