Provided by: manpages-de-dev_4.21.0-2_all bug

BEZEICHNUNG

       setjmp, sigsetjmp, longjmp, siglongjmp - Nichtlokalen Sprungbefehl durchführen

BIBLIOTHEK

       Standard-C-Bibliothek (libc, -lc)

ÜBERSICHT

       #include <setjmp.h>

       int setjmp(jmp_buf Umg);
       int sigsetjmp(sigjmp_buf Umg, int speicherSig);

       [[noreturn]] void longjmp(jmp_buf Umg, int Wert);
       [[noreturn]] void siglongjmp(sigjmp_buf Umg, int Wert);

   Mit Glibc erforderliche Feature-Test-Makros (siehe feature_test_macros(7)):

       setjmp(): siehe ANMERKUNGEN.

       sigsetjmp():
           _POSIX_C_SOURCE

BESCHREIBUNG

       Die  auf  dieser  Seite  beschriebenen  Funktionen  werden für »nichtlokale Gotos« verwandt: Übergabe der
       Ausführung von einer Funktion zu einer vorbestimmten Stelle  in  einer  anderen  Funktion.  Die  Funktion
       setjmp() etabliert dynamisch das Ziel, zu dem die Steuerung später übergeben wird und longjmp() führt den
       Ausführungstransfer aus.

       Die  Funktion  setjmp() speichert verschiedene Informationen über die aufrufende Umgebung (typischerweise
       den  Stack-Zeiger,  den  Anweisungszeiger,  möglicherweise  die  Werte  von  anderen  Registern  und  die
       Signalmaske)  im Puffer Umg für die spätere Verwendung durch longjmp(). In diesem Fall liefert setjmp() 0
       zurück.

       Die Funktion longjmp() verwendet die in Umg gespeicherten Informationen, um die Steuerung  zu  dem  Punkt
       zurückzuübergeben,  an  dem setjmp() aufgerufen worden war und den Stack auf seinem Zustand zum Zeitpunkt
       des  Aufrufs  von  setjmp()  wiederherzustellen  (»zurückzuspulen«).  Zusätzlich  und  abhängig  von  der
       Implementierung  (siehe ANMERKUNGEN) können die Werte einiger anderer Register und der Prozesssignalmaske
       auf den Wert zum Zeitpunkt des Aufrufs von setjmp() wiederhergestellt werden.

       Nach einem erfolgreichen longjmp() fährt die  Ausführung  so  fort,  als  ob  setjmp()  ein  zweites  Mal
       zurückgekehrt  wäre.  Diese  »Schummel«-Rückkehr  kann von einem echten Aufruf von setjmp() unterschieden
       werden,  da  die  »Schummel«-Rückkehr  den  in  Wert  bereitgestellten  Wert  zurückliefert.  Falls   der
       Programmierer fehlerhafterweise den Wert 0 in Wert weitergibt, wird die »Schummel«-Rückkehr stattdessen 1
       zurückliefern.

   sigsetjmp() und siglongjmp()
       sigsetjmp()  und  siglongjmp()  führen  auch  nichtlokale  Gotos  durch,  stellen aber eine vorhersehbare
       Behandlung der Prozesssignalmaske bereit.

       Nur wenn das an sigsetjmp() übergebene Argument speicherSig nicht Null ist, wird die aktuelle Signalmaske
       des Prozesses in Umg gespeichert und  wiederhergestellt,  wenn  später  mit  diesem  Umg  ein  siglongjmp
       durchgeführt wird.

RÜCKGABEWERT

       setjmp()  und  sigsetjmp()  geben  0  zurück,  wenn  sie direkt aufgerufen wurden; bei dem »nachgeahmten«
       Zurückkehren, das nach longjmp() und siglongjmp() auftritt, wird der in  Wert  angegebene  Nichtnull-Wert
       zurückgegeben.

       Die Funktionen longjmp() oder siglongjmp() kehren nicht zurück.

ATTRIBUTE

       Siehe attributes(7) für eine Erläuterung der in diesem Abschnitt verwandten Ausdrücke.
       ┌─────────────────────────────────────────────────────────────────────┬───────────────────────┬─────────┐
       │ SchnittstelleAttributWert    │
       ├─────────────────────────────────────────────────────────────────────┼───────────────────────┼─────────┤
       │ setjmp(), sigsetjmp()                                               │ Multithread-Fähigkeit │ MT-Safe │
       ├─────────────────────────────────────────────────────────────────────┼───────────────────────┼─────────┤
       │ longjmp(), siglongjmp()                                             │ Multithread-Fähigkeit │ MT-Safe │
       └─────────────────────────────────────────────────────────────────────┴───────────────────────┴─────────┘

STANDARDS

       setjmp(), longjmp(): POSIX.1-2001, POSIX.1-2008, C99.

       sigsetjmp(), siglongjmp(): POSIX.1-2001, POSIX.1-2008.

ANMERKUNGEN

       POSIX  spezifiziert nicht, ob setjmp() die Signalmaske sichern wird (um sie später während longjmp() wie‐
       der herzustellen). In System-V wird es dies nicht tun. In 4.3BSD wird es dies tun und dort gibt  es  eine
       Funktion  _setjmp(), die es nicht tut. Das Verhalten unter Linux hängt von der Glibc-Version und den Ein‐
       stellungen der Feature-Test-Makros ab. Vor Glibc 2.19 folgte setjmp() standardmäßig dem Verhalten von Sy‐
       stem V, aber das BSD-Verhalten wird bereitgestellt, wenn das _BSD_SOURCE-Feature-Test-Macro explizit  de‐
       finiert  ist und weder _POSIX_SOURCE, _POSIX_C_SOURCE, _XOPEN_SOURCE, _GNU_SOURCE noch _SVID_SOURCE defi‐
       niert ist. Seit Glibc 2.19 stellt <setjmp.h> nur die System-V-Version von setjmp() bereit. Programme, die
       die BSD-Semantik benötigen, sollten Aufrufe von setjmp() durch Aufrufe von sigsetjmp(), bei denen das Ar‐
       gument speicherSig ungleich numerisch Null ist, ersetzen.

       setjmp() und longjmp() können zum Umgang mit Fehlern innerhalb tiefverschachtelter Funktionsaufrufe nütz‐
       lich sein oder um einem Signal-Handler zu ermöglichen, die Steuerung an einen  bestimmten  Punkt  in  dem
       Programm  zu übergeben, statt zu dem Punkt zurückzukehren, in dem der Handler das Hauptprogramm unterbro‐
       chen hat. In letzterem Falle verwenden Sie sigsetjmp() und siglongjmp(), falls Sie die Signalmaske porta‐
       bel speichern und wiederherstellen möchten. Lesen Sie auch die Diskussion zur  Programmlesbarkeit  weiter
       unten.

       Der  Compiler kann Variablen in Register optimieren und longjmp() kann die Werte anderer Register zusätz‐
       lich zum Stack- und Programmzeiger wiederherstellen. Daher ist der Wert von automatischen Variablen  nach
       einem Aufruf von longjmp() undefiniert, falls alle folgenden Kriterien zutreffen:

       •  sie sind für die Funktion, die den entsprechenden Aufruf setjmp() durchführte, lokal,

       •  ihre Werte sind zwischen Aufrufen von setjmp() und longjmp() geändert, und

       •  sie sind nicht als volatile deklariert.

       Entsprechende Anmerkungen gelten für siglongjmp().

   Nicht lokale GOTOs und Programmlesbarkeit
       Auch  wenn er missbraucht werden kann, hat der traditionelle »goto«-Ausdruck von C zumindest den Vorteil,
       dass lexikalische Hinweise (der Goto-Ausdruck und die Zielmarkierung) dem Programmierer erlauben,  leicht
       den  Ablauf  zu  verstehen.  Nichtlokale Gotos stellen keine solchen Hinweise bereit: Mehrere Aufrufe von
       setjmp() können die gleiche Variable jmp_buf einsetzen, so dass der Inhalt der Variablen  sich  über  die
       Lebensdauer  des Programmes verändern kann. Konsequenterweise kann der Programmierer dazu gezwungen sein,
       den Code detailliert zu lesen, um das dynamische Ziel eines bestimmten Aufrufs von  longjmp()  zu  ermit‐
       teln. (Um das Leben der Programmierer zu erleichtern, sollte jeder Aufruf von setjmp() eine eineindeutige
       Variable jmp_buf einsetzen.)

       Weitere  Schwierigkeiten  kommen hinzu, da die Aufrufe von setjmp() und longjmp() nicht zwingend im glei‐
       chen Quellcodemodul sein müssen.

       Zusammenfassend erschweren nicht lokale GOTOs das Verständnis und die Verwaltung  von  Programmen.  Falls
       möglich, sollte eine Alternative benutzt werden.

   Warnungen
       Falls die Funktion, die setjmp() aufruft, zurückkehrt, bevor longjmp() aufgerufen wird, ist das Verhalten
       undefiniert. Irgendwelches subtiles oder nicht so subtiles Chaos entsteht bestimmt dadurch.

       Falls  ein  longjmp()-Aufruf  in einem Programm mit mehreren Threads einen Umg-Puffer einsetzt, der durch
       einen Aufruf von setjmp() in einem anderen Thread initialisiert wurde, ist  sein  Verhalten  nicht  defi‐
       niert.

       POSIX.1-2008  Technische  Berichtigung 2 fügt longjmp() und siglongjmp() zur Liste der asynchronsignalsi‐
       cheren Funktionen hinzu. Der Standard empfiehlt jedoch den Gebrauch dieser Funktionen aus Signal-Handlern
       zu vermeiden. Sie fährt damit fort, zu betonen, dass, falls diese  Funktionen  von  einem  Signal-Handler
       aufgerufen werden, der einen Aufruf einer nicht asynchronsignalsicheren Funktion unterbrochen hatte (oder
       etwas gleichbedeutendem, wie den Schritten, die exit(3) entsprechen, die über eine Rückkehr vom initialen
       Aufruf zu main() auftreten), das Verhalten nicht definiert ist, falls das Programm nachfolgend einen Auf‐
       ruf einer nicht asynchronsignalsicheren Funktion durchführt. Der einzige Weg, nicht definiertes Verhalten
       zu vermeiden, ist, eines des Nachfolgenden sicherzustellen:

       •  Nach langen Sprüngen vom Signal-Handler ruft das Programm keine asynchronsignalsicheren Funktionen auf
          und kehrt nicht vom initialen Aufruf von main() zurück.

       •  Jedes  Signal,  dessen  Handler einen langen Sprung durchführt, muss während jedes Aufrufs einer nicht
          asynchronsignalsicheren Funktion blockiert werden und keine nicht  asynchronsignalsicheren  Funktionen
          werden nach der Rückkehr vom initialen Aufruf von main() aufgerufen.

SIEHE AUCH

       signal(7), signal-safety(7)

ÜBERSETZUNG

       Die  deutsche  Übersetzung  dieser  Handbuchseite  wurde  von  Patrick Rother <krd@gulu.net>, Chris Leick
       <c.leick@vollbio.de>, Dr. Tobias Quathamer <toddy@debian.org>,  Helge  Kreutzmann  <debian@helgefjell.de>
       und Mario Blättermann <mario.blaettermann@gmail.com> erstellt.

       Diese  Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer
       bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte  eine  E-Mail  an  die
       Mailingliste der Übersetzer.

Linux man-pages 6.03                             5. Februar 2023                                       setjmp(3)