Zagnieżdzanie pętli - problem klamer

Witam,

jestem początkującym programistą i mam problem z zagnieżdżaniem pętli w języku C, a właściwie to formułę całą rozumiem, tylko nie umiem poradzić sobie z klamrami zamykającymi i otwierającymi pętle.
Przykładowo mam pętle:

for(...) {
...
for(...) {
...
}
...
}

I chciałbym, aby pierwszy for kończył się wraz z 3 klamrą w przykładzie (pierwszą zamykającą), natomiast zawsze to zamknięcie łapie mi się do fora środkowego.
Wie ktoś może jak wyjść z tej sytuacji?

Czyli chcesz mieć coś takiego mniej-więcej?

pętla 1
pętla 1
pętla 1
pętla 1 i 2
pętla 1 i 2
pętla 1 i 2
pętla 1 i 2
pętla 2
pętla 2

Jeśli tak, to samą pętlą tego nie ogarniesz. Potrzebujesz zmienić logikę, na przykład wprowadzając instrukcje warunkowe.

1. To co chcesz zrobić to jakiś ciężki WTF i trudno mi sobie wyobrazić sytuacje kiedy to by miało jakikolwiek sens.
2. W ogóle nie zagnieżdżaj pętli. Jeśli funkcja ma więcej niz 1 poziom zagnieżdżenia (albo 2 jeśli to for + if) to znaczy że należy ją podzielić na kawałki. Cały "środek" tej pętli wyrzuca się do osobnej funkcji.

Wiem, że takie użycie wydaje się bezsensowne, dlatego może wytłumaczę skąd moje wątpliwości.
Otóż przerabiam program z języka FORTRAN na język C. Jest to program o dużej ilości etykiet, przeskoków GOTO, ogólnie nie wygląda to zbyt schludnie, kod ten jest bardzo wiekowy.
W Fortranie zamiast FOR'a istnieje pętla DO, np. DO 50 i=1,5 - oznacza to, iż pętla działa od miejsca napisania słowa kluczowego DO, a kończy się po wykonaniu etykiety o numerze 50. Zmienna i powiększa się po każdym przejściu pętli o 1, aż wyrówna się z podaną następną wartością (w tym przypadku 5, pętla ta wykona się 5 razy).
W kodzie nad którym pracuje jest bardzo dużo takich pętli DO, często jedna w drugiej. Może macie pomysł na inne obejście tej sytuacji, bez konieczności zmiany logiki całego programu? Nad samym przełożeniem kodu wprost spędziłem już dosyć dużo czasu.

Extract method, nie widzę tu przeciwwskazań.

Przeczytałem trochę o tej metodzie, ale nie za bardzo potrafię sobie wyobrazić jakby to miało wyglądać...

Właśnie dlatego nowe języki w ogóle nie wspierają goto i takich dzikich skoków. Bo potem analiza takiego kodu jest praktycznie niemożliwa. Zamiast spróbować symulować to szaleństwo w języku który się przed tym broni przepisz to po ludzku.