Hallo Mitübersetzer,
ich habe kürzlich eine Handbuchseite aus Abschnitt 7 übersetzt.
Es sind insgesamt 62 Zeichenketten, pro Teil ca. 20.
Für konstruktives Korrekturlesen wäre ich sehr dankbar.
Diese Handbuchseite war schwer zu übersetzen, daher holpert es
an einigen Stellen noch. Auch denke ich, die Schlagwörter wie MT-Safe
in allen Handbuchseiten (und dann auch hier) zu übersetzen, dann
holpern die Sätze hier nicht und auch in den anderen Handbuchseiten
wird es konsequenter deutsch.
Viele Grüße
Helge
P.S. Die Handbuchseite erhalten umfangreiche Kommentare und die Teile
wirken daher sehr groß, aber die Kommentare können beim Lesen ja
überblättert werden, der Leser sieht sie ja auch nicht.
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
#
#
#
#
#
#. Functions marked with
#. .I init
#. as an AS-Unsafe or AC-Unsafe feature use the GNU C Library internal
#. .I libc_once
#. machinery or similar to initialize internal data structures.
#. If a signal handler interrupts such an initializer,
#. and calls any function that also performs
#. .I libc_once
#. initialization, it will deadlock if the thread library has been loaded.
#. Furthermore, if an initializer is partially complete before it is canceled
#. or interrupted by a signal whose handler requires the same initialization,
#. some or all of the initialization may be performed more than once,
#. leaking resources or even resulting in corrupt internal data.
#. Applications that need to call functions marked with
#. .I init
#. as an AS-Safety or AC-Unsafe feature should ensure
#. the initialization is performed
#. before configuring signal handlers or enabling cancelation,
#. so that the AS-Safety and AC-Safety issues related with
#. .I libc_once
#. do not arise.
#. .\" We may have to extend the annotations to cover conditions in which
#. .\" initialization may or may not occur, since an initial call in a safe
#. .\" context is no use if the initialization doesn't take place at that
#. .\" time: it doesn't remove the risk for later calls.
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"Calling such a function at least once in single-threaded mode removes this "
"specific cause for the function to be regarded as MT-Unsafe. If no other "
"cause for that remains, the function can then be safely called after other "
"threads are started."
msgstr ""
"Durch mindestens einmaligen Aufruf dieser Funktion in einem Einzel-Thread-"
"Modus wird dieser bestimmte Grund, aus dem die Funktion als MT-Unsafe "
"betrachtet wird, entfernt. Falls dafür kein weiterer Grund verbleibt, kann "
"diese Funktion sicher aufgerufen werden, nachdem andere Threads gestartet "
"wurden."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I<race>"
msgstr "I<race>"
#
#
#
#
#
#
#
#. #-#-#-#-# archlinux: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. We consider access to objects passed as (indirect) arguments to
#. functions to be data race free.
#. The assurance of data race free objects
#. is the caller's responsibility.
#. We will not mark a function as MT-Unsafe or AS-Unsafe
#. if it misbehaves when users fail to take the measures required by
#. POSIX to avoid data races when dealing with such objects.
#. As a general rule, if a function is documented as reading from
#. an object passed (by reference) to it, or modifying it,
#. users ought to use memory synchronization primitives
#. to avoid data races just as they would should they perform
#. the accesses themselves rather than by calling the library function.
#. Standard I/O
#. .RI ( "FILE *" )
#. streams are the exception to the general rule,
#. in that POSIX mandates the library to guard against data races
#. in many functions that manipulate objects of this specific opaque type.
#. We regard this as a convenience provided to users,
#. rather than as a general requirement whose expectations
#. should extend to other types.
#. In order to remind users that guarding certain arguments is their
#. responsibility, we will annotate functions that take objects of certain
#. types as arguments.
#. We draw the line for objects passed by users as follows:
#. objects whose types are exposed to users,
#. and that users are expected to access directly,
#. such as memory buffers, strings,
#. and various user-visible structured types, do
#. .I not
#. give reason for functions to be annotated with
#. .IR race .
#. It would be noisy and redundant with the general requirement,
#. and not many would be surprised by the library's lack of internal
#. guards when accessing objects that can be accessed directly by users.
#. As for objects that are opaque or opaque-like,
#. in that they are to be manipulated only by passing them
#. to library functions (e.g.,
#. .IR FILE ,
#. .IR DIR ,
#. .IR obstack ,
#. .IR iconv_t ),
#. there might be additional expectations as to internal coordination
#. of access by the library.
#. We will annotate, with
#. .I race
#. followed by a colon and the argument name,
#. functions that take such objects but that do not take
#. care of synchronizing access to them by default.
#. For example,
#. .I FILE
#. stream
#. .I unlocked
#. functions
#. .RB ( unlocked_stdio (3))
#. will be annotated,
#. but those that perform implicit locking on
#. .I FILE
#. streams by default will not,
#. even though the implicit locking may be disabled on a per-stream basis.
#. In either case, we will not regard as MT-Unsafe functions that may
#. access user-supplied objects in unsafe ways should users fail to ensure
#. the accesses are well defined.
#. The notion prevails that users are expected to safeguard against
#. data races any user-supplied objects that the library accesses
#. on their behalf.
#. .\" The above describes @mtsrace; @mtasurace is described below.
#. This user responsibility does not apply, however,
#. to objects controlled by the library itself,
#. such as internal objects and static buffers used
#. to return values from certain calls.
#. When the library doesn't guard them against concurrent uses,
#. these cases are regarded as MT-Unsafe and AS-Unsafe (although the
#. .I race
#. mark under AS-Unsafe will be omitted
#. as redundant with the one under MT-Unsafe).
#. As in the case of user-exposed objects,
#. the mark may be followed by a colon and an identifier.
#. The identifier groups all functions that operate on a
#. certain unguarded object; users may avoid the MT-Safety issues related
#. with unguarded concurrent access to such internal objects by creating a
#. non-recursive mutex related with the identifier,
#. and always holding the mutex when calling any function marked
#. as racy on that identifier,
#. as they would have to should the identifier be
#. an object under user control.
#. The non-recursive mutex avoids the MT-Safety issue,
#. but it trades one AS-Safety issue for another,
#. so use in asynchronous signals remains undefined.
#. When the identifier relates to a static buffer used to hold return values,
#. the mutex must be held for as long as the buffer remains in use
#. by the caller.
#. Many functions that return pointers to static buffers offer reentrant
#. variants that store return values in caller-supplied buffers instead.
#. In some cases, such as
#. .BR tmpname (3),
#. the variant is chosen not by calling an alternate entry point,
#. but by passing a non-NULL pointer to the buffer in which the
#. returned values are to be stored.
#. These variants are generally preferable in multi-threaded programs,
#. although some of them are not MT-Safe because of other internal buffers,
#. also documented with
#. .I race
#. notes.
#. type: Plain text
#. #-#-#-#-# debian-bookworm: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. We consider access to objects passed as (indirect) arguments to
#. functions to be data race free.
#. The assurance of data race free objects
#. is the caller's responsibility.
#. We will not mark a function as MT-Unsafe or AS-Unsafe
#. if it misbehaves when users fail to take the measures required by
#. POSIX to avoid data races when dealing with such objects.
#. As a general rule, if a function is documented as reading from
#. an object passed (by reference) to it, or modifying it,
#. users ought to use memory synchronization primitives
#. to avoid data races just as they would should they perform
#. the accesses themselves rather than by calling the library function.
#. Standard I/O
#. .RI ( "FILE *" )
#. streams are the exception to the general rule,
#. in that POSIX mandates the library to guard against data races
#. in many functions that manipulate objects of this specific opaque type.
#. We regard this as a convenience provided to users,
#. rather than as a general requirement whose expectations
#. should extend to other types.
#. In order to remind users that guarding certain arguments is their
#. responsibility, we will annotate functions that take objects of certain
#. types as arguments.
#. We draw the line for objects passed by users as follows:
#. objects whose types are exposed to users,
#. and that users are expected to access directly,
#. such as memory buffers, strings,
#. and various user-visible structured types, do
#. .I not
#. give reason for functions to be annotated with
#. .IR race .
#. It would be noisy and redundant with the general requirement,
#. and not many would be surprised by the library's lack of internal
#. guards when accessing objects that can be accessed directly by users.
#. As for objects that are opaque or opaque-like,
#. in that they are to be manipulated only by passing them
#. to library functions (e.g.,
#. .IR FILE ,
#. .IR DIR ,
#. .IR obstack ,
#. .IR iconv_t ),
#. there might be additional expectations as to internal coordination
#. of access by the library.
#. We will annotate, with
#. .I race
#. followed by a colon and the argument name,
#. functions that take such objects but that do not take
#. care of synchronizing access to them by default.
#. For example,
#. .I FILE
#. stream
#. .I unlocked
#. functions
#. .RB ( unlocked_stdio (3))
#. will be annotated,
#. but those that perform implicit locking on
#. .I FILE
#. streams by default will not,
#. even though the implicit locking may be disabled on a per-stream basis.
#. In either case, we will not regard as MT-Unsafe functions that may
#. access user-supplied objects in unsafe ways should users fail to ensure
#. the accesses are well defined.
#. The notion prevails that users are expected to safeguard against
#. data races any user-supplied objects that the library accesses
#. on their behalf.
#. .\" The above describes @mtsrace; @mtasurace is described below.
#. This user responsibility does not apply, however,
#. to objects controlled by the library itself,
#. such as internal objects and static buffers used
#. to return values from certain calls.
#. When the library doesn't guard them against concurrent uses,
#. these cases are regarded as MT-Unsafe and AS-Unsafe (although the
#. .I race
#. mark under AS-Unsafe will be omitted
#. as redundant with the one under MT-Unsafe).
#. As in the case of user-exposed objects,
#. the mark may be followed by a colon and an identifier.
#. The identifier groups all functions that operate on a
#. certain unguarded object; users may avoid the MT-Safety issues related
#. with unguarded concurrent access to such internal objects by creating a
#. non-recursive mutex related with the identifier,
#. and always holding the mutex when calling any function marked
#. as racy on that identifier,
#. as they would have to should the identifier be
#. an object under user control.
#. The non-recursive mutex avoids the MT-Safety issue,
#. but it trades one AS-Safety issue for another,
#. so use in asynchronous signals remains undefined.
#. When the identifier relates to a static buffer used to hold return values,
#. the mutex must be held for as long as the buffer remains in use
#. by the caller.
#. Many functions that return pointers to static buffers offer reentrant
#. variants that store return values in caller-supplied buffers instead.
#. In some cases, such as
#. .BR tmpname (3),
#. the variant is chosen not by calling an alternate entry point,
#. but by passing a non-NULL pointer to the buffer in which the
#. returned values are to be stored.
#. These variants are generally preferable in multi-threaded programs,
#. although some of them are not MT-Safe because of other internal buffers,
#. also documented with
#. .I race
#. notes.
#. type: Plain text
#. #-#-#-#-# debian-unstable: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. We consider access to objects passed as (indirect) arguments to
#. functions to be data race free.
#. The assurance of data race free objects
#. is the caller's responsibility.
#. We will not mark a function as MT-Unsafe or AS-Unsafe
#. if it misbehaves when users fail to take the measures required by
#. POSIX to avoid data races when dealing with such objects.
#. As a general rule, if a function is documented as reading from
#. an object passed (by reference) to it, or modifying it,
#. users ought to use memory synchronization primitives
#. to avoid data races just as they would should they perform
#. the accesses themselves rather than by calling the library function.
#. Standard I/O
#. .RI ( "FILE *" )
#. streams are the exception to the general rule,
#. in that POSIX mandates the library to guard against data races
#. in many functions that manipulate objects of this specific opaque type.
#. We regard this as a convenience provided to users,
#. rather than as a general requirement whose expectations
#. should extend to other types.
#. In order to remind users that guarding certain arguments is their
#. responsibility, we will annotate functions that take objects of certain
#. types as arguments.
#. We draw the line for objects passed by users as follows:
#. objects whose types are exposed to users,
#. and that users are expected to access directly,
#. such as memory buffers, strings,
#. and various user-visible structured types, do
#. .I not
#. give reason for functions to be annotated with
#. .IR race .
#. It would be noisy and redundant with the general requirement,
#. and not many would be surprised by the library's lack of internal
#. guards when accessing objects that can be accessed directly by users.
#. As for objects that are opaque or opaque-like,
#. in that they are to be manipulated only by passing them
#. to library functions (e.g.,
#. .IR FILE ,
#. .IR DIR ,
#. .IR obstack ,
#. .IR iconv_t ),
#. there might be additional expectations as to internal coordination
#. of access by the library.
#. We will annotate, with
#. .I race
#. followed by a colon and the argument name,
#. functions that take such objects but that do not take
#. care of synchronizing access to them by default.
#. For example,
#. .I FILE
#. stream
#. .I unlocked
#. functions
#. .RB ( unlocked_stdio (3))
#. will be annotated,
#. but those that perform implicit locking on
#. .I FILE
#. streams by default will not,
#. even though the implicit locking may be disabled on a per-stream basis.
#. In either case, we will not regard as MT-Unsafe functions that may
#. access user-supplied objects in unsafe ways should users fail to ensure
#. the accesses are well defined.
#. The notion prevails that users are expected to safeguard against
#. data races any user-supplied objects that the library accesses
#. on their behalf.
#. .\" The above describes @mtsrace; @mtasurace is described below.
#. This user responsibility does not apply, however,
#. to objects controlled by the library itself,
#. such as internal objects and static buffers used
#. to return values from certain calls.
#. When the library doesn't guard them against concurrent uses,
#. these cases are regarded as MT-Unsafe and AS-Unsafe (although the
#. .I race
#. mark under AS-Unsafe will be omitted
#. as redundant with the one under MT-Unsafe).
#. As in the case of user-exposed objects,
#. the mark may be followed by a colon and an identifier.
#. The identifier groups all functions that operate on a
#. certain unguarded object; users may avoid the MT-Safety issues related
#. with unguarded concurrent access to such internal objects by creating a
#. non-recursive mutex related with the identifier,
#. and always holding the mutex when calling any function marked
#. as racy on that identifier,
#. as they would have to should the identifier be
#. an object under user control.
#. The non-recursive mutex avoids the MT-Safety issue,
#. but it trades one AS-Safety issue for another,
#. so use in asynchronous signals remains undefined.
#. When the identifier relates to a static buffer used to hold return values,
#. the mutex must be held for as long as the buffer remains in use
#. by the caller.
#. Many functions that return pointers to static buffers offer reentrant
#. variants that store return values in caller-supplied buffers instead.
#. In some cases, such as
#. .BR tmpname (3),
#. the variant is chosen not by calling an alternate entry point,
#. but by passing a non-NULL pointer to the buffer in which the
#. returned values are to be stored.
#. These variants are generally preferable in multi-threaded programs,
#. although some of them are not MT-Safe because of other internal buffers,
#. also documented with
#. .I race
#. notes.
#. type: Plain text
#. #-#-#-#-# fedora-40: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. We consider access to objects passed as (indirect) arguments to
#. functions to be data race free.
#. The assurance of data race free objects
#. is the caller's responsibility.
#. We will not mark a function as MT-Unsafe or AS-Unsafe
#. if it misbehaves when users fail to take the measures required by
#. POSIX to avoid data races when dealing with such objects.
#. As a general rule, if a function is documented as reading from
#. an object passed (by reference) to it, or modifying it,
#. users ought to use memory synchronization primitives
#. to avoid data races just as they would should they perform
#. the accesses themselves rather than by calling the library function.
#. Standard I/O
#. .RI ( "FILE *" )
#. streams are the exception to the general rule,
#. in that POSIX mandates the library to guard against data races
#. in many functions that manipulate objects of this specific opaque type.
#. We regard this as a convenience provided to users,
#. rather than as a general requirement whose expectations
#. should extend to other types.
#. In order to remind users that guarding certain arguments is their
#. responsibility, we will annotate functions that take objects of certain
#. types as arguments.
#. We draw the line for objects passed by users as follows:
#. objects whose types are exposed to users,
#. and that users are expected to access directly,
#. such as memory buffers, strings,
#. and various user-visible structured types, do
#. .I not
#. give reason for functions to be annotated with
#. .IR race .
#. It would be noisy and redundant with the general requirement,
#. and not many would be surprised by the library's lack of internal
#. guards when accessing objects that can be accessed directly by users.
#. As for objects that are opaque or opaque-like,
#. in that they are to be manipulated only by passing them
#. to library functions (e.g.,
#. .IR FILE ,
#. .IR DIR ,
#. .IR obstack ,
#. .IR iconv_t ),
#. there might be additional expectations as to internal coordination
#. of access by the library.
#. We will annotate, with
#. .I race
#. followed by a colon and the argument name,
#. functions that take such objects but that do not take
#. care of synchronizing access to them by default.
#. For example,
#. .I FILE
#. stream
#. .I unlocked
#. functions
#. .RB ( unlocked_stdio (3))
#. will be annotated,
#. but those that perform implicit locking on
#. .I FILE
#. streams by default will not,
#. even though the implicit locking may be disabled on a per-stream basis.
#. In either case, we will not regard as MT-Unsafe functions that may
#. access user-supplied objects in unsafe ways should users fail to ensure
#. the accesses are well defined.
#. The notion prevails that users are expected to safeguard against
#. data races any user-supplied objects that the library accesses
#. on their behalf.
#. .\" The above describes @mtsrace; @mtasurace is described below.
#. This user responsibility does not apply, however,
#. to objects controlled by the library itself,
#. such as internal objects and static buffers used
#. to return values from certain calls.
#. When the library doesn't guard them against concurrent uses,
#. these cases are regarded as MT-Unsafe and AS-Unsafe (although the
#. .I race
#. mark under AS-Unsafe will be omitted
#. as redundant with the one under MT-Unsafe).
#. As in the case of user-exposed objects,
#. the mark may be followed by a colon and an identifier.
#. The identifier groups all functions that operate on a
#. certain unguarded object; users may avoid the MT-Safety issues related
#. with unguarded concurrent access to such internal objects by creating a
#. non-recursive mutex related with the identifier,
#. and always holding the mutex when calling any function marked
#. as racy on that identifier,
#. as they would have to should the identifier be
#. an object under user control.
#. The non-recursive mutex avoids the MT-Safety issue,
#. but it trades one AS-Safety issue for another,
#. so use in asynchronous signals remains undefined.
#. When the identifier relates to a static buffer used to hold return values,
#. the mutex must be held for as long as the buffer remains in use
#. by the caller.
#. Many functions that return pointers to static buffers offer reentrant
#. variants that store return values in caller-supplied buffers instead.
#. In some cases, such as
#. .BR tmpname (3),
#. the variant is chosen not by calling an alternate entry point,
#. but by passing a non-null pointer to the buffer in which the
#. returned values are to be stored.
#. These variants are generally preferable in multi-threaded programs,
#. although some of them are not MT-Safe because of other internal buffers,
#. also documented with
#. .I race
#. notes.
#. type: Plain text
#. #-#-#-#-# fedora-rawhide: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. We consider access to objects passed as (indirect) arguments to
#. functions to be data race free.
#. The assurance of data race free objects
#. is the caller's responsibility.
#. We will not mark a function as MT-Unsafe or AS-Unsafe
#. if it misbehaves when users fail to take the measures required by
#. POSIX to avoid data races when dealing with such objects.
#. As a general rule, if a function is documented as reading from
#. an object passed (by reference) to it, or modifying it,
#. users ought to use memory synchronization primitives
#. to avoid data races just as they would should they perform
#. the accesses themselves rather than by calling the library function.
#. Standard I/O
#. .RI ( "FILE *" )
#. streams are the exception to the general rule,
#. in that POSIX mandates the library to guard against data races
#. in many functions that manipulate objects of this specific opaque type.
#. We regard this as a convenience provided to users,
#. rather than as a general requirement whose expectations
#. should extend to other types.
#. In order to remind users that guarding certain arguments is their
#. responsibility, we will annotate functions that take objects of certain
#. types as arguments.
#. We draw the line for objects passed by users as follows:
#. objects whose types are exposed to users,
#. and that users are expected to access directly,
#. such as memory buffers, strings,
#. and various user-visible structured types, do
#. .I not
#. give reason for functions to be annotated with
#. .IR race .
#. It would be noisy and redundant with the general requirement,
#. and not many would be surprised by the library's lack of internal
#. guards when accessing objects that can be accessed directly by users.
#. As for objects that are opaque or opaque-like,
#. in that they are to be manipulated only by passing them
#. to library functions (e.g.,
#. .IR FILE ,
#. .IR DIR ,
#. .IR obstack ,
#. .IR iconv_t ),
#. there might be additional expectations as to internal coordination
#. of access by the library.
#. We will annotate, with
#. .I race
#. followed by a colon and the argument name,
#. functions that take such objects but that do not take
#. care of synchronizing access to them by default.
#. For example,
#. .I FILE
#. stream
#. .I unlocked
#. functions
#. .RB ( unlocked_stdio (3))
#. will be annotated,
#. but those that perform implicit locking on
#. .I FILE
#. streams by default will not,
#. even though the implicit locking may be disabled on a per-stream basis.
#. In either case, we will not regard as MT-Unsafe functions that may
#. access user-supplied objects in unsafe ways should users fail to ensure
#. the accesses are well defined.
#. The notion prevails that users are expected to safeguard against
#. data races any user-supplied objects that the library accesses
#. on their behalf.
#. .\" The above describes @mtsrace; @mtasurace is described below.
#. This user responsibility does not apply, however,
#. to objects controlled by the library itself,
#. such as internal objects and static buffers used
#. to return values from certain calls.
#. When the library doesn't guard them against concurrent uses,
#. these cases are regarded as MT-Unsafe and AS-Unsafe (although the
#. .I race
#. mark under AS-Unsafe will be omitted
#. as redundant with the one under MT-Unsafe).
#. As in the case of user-exposed objects,
#. the mark may be followed by a colon and an identifier.
#. The identifier groups all functions that operate on a
#. certain unguarded object; users may avoid the MT-Safety issues related
#. with unguarded concurrent access to such internal objects by creating a
#. non-recursive mutex related with the identifier,
#. and always holding the mutex when calling any function marked
#. as racy on that identifier,
#. as they would have to should the identifier be
#. an object under user control.
#. The non-recursive mutex avoids the MT-Safety issue,
#. but it trades one AS-Safety issue for another,
#. so use in asynchronous signals remains undefined.
#. When the identifier relates to a static buffer used to hold return values,
#. the mutex must be held for as long as the buffer remains in use
#. by the caller.
#. Many functions that return pointers to static buffers offer reentrant
#. variants that store return values in caller-supplied buffers instead.
#. In some cases, such as
#. .BR tmpname (3),
#. the variant is chosen not by calling an alternate entry point,
#. but by passing a non-NULL pointer to the buffer in which the
#. returned values are to be stored.
#. These variants are generally preferable in multi-threaded programs,
#. although some of them are not MT-Safe because of other internal buffers,
#. also documented with
#. .I race
#. notes.
#. type: Plain text
#. #-#-#-#-# mageia-cauldron: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. We consider access to objects passed as (indirect) arguments to
#. functions to be data race free.
#. The assurance of data race free objects
#. is the caller's responsibility.
#. We will not mark a function as MT-Unsafe or AS-Unsafe
#. if it misbehaves when users fail to take the measures required by
#. POSIX to avoid data races when dealing with such objects.
#. As a general rule, if a function is documented as reading from
#. an object passed (by reference) to it, or modifying it,
#. users ought to use memory synchronization primitives
#. to avoid data races just as they would should they perform
#. the accesses themselves rather than by calling the library function.
#. Standard I/O
#. .RI ( "FILE *" )
#. streams are the exception to the general rule,
#. in that POSIX mandates the library to guard against data races
#. in many functions that manipulate objects of this specific opaque type.
#. We regard this as a convenience provided to users,
#. rather than as a general requirement whose expectations
#. should extend to other types.
#. In order to remind users that guarding certain arguments is their
#. responsibility, we will annotate functions that take objects of certain
#. types as arguments.
#. We draw the line for objects passed by users as follows:
#. objects whose types are exposed to users,
#. and that users are expected to access directly,
#. such as memory buffers, strings,
#. and various user-visible structured types, do
#. .I not
#. give reason for functions to be annotated with
#. .IR race .
#. It would be noisy and redundant with the general requirement,
#. and not many would be surprised by the library's lack of internal
#. guards when accessing objects that can be accessed directly by users.
#. As for objects that are opaque or opaque-like,
#. in that they are to be manipulated only by passing them
#. to library functions (e.g.,
#. .IR FILE ,
#. .IR DIR ,
#. .IR obstack ,
#. .IR iconv_t ),
#. there might be additional expectations as to internal coordination
#. of access by the library.
#. We will annotate, with
#. .I race
#. followed by a colon and the argument name,
#. functions that take such objects but that do not take
#. care of synchronizing access to them by default.
#. For example,
#. .I FILE
#. stream
#. .I unlocked
#. functions
#. .RB ( unlocked_stdio (3))
#. will be annotated,
#. but those that perform implicit locking on
#. .I FILE
#. streams by default will not,
#. even though the implicit locking may be disabled on a per-stream basis.
#. In either case, we will not regard as MT-Unsafe functions that may
#. access user-supplied objects in unsafe ways should users fail to ensure
#. the accesses are well defined.
#. The notion prevails that users are expected to safeguard against
#. data races any user-supplied objects that the library accesses
#. on their behalf.
#. .\" The above describes @mtsrace; @mtasurace is described below.
#. This user responsibility does not apply, however,
#. to objects controlled by the library itself,
#. such as internal objects and static buffers used
#. to return values from certain calls.
#. When the library doesn't guard them against concurrent uses,
#. these cases are regarded as MT-Unsafe and AS-Unsafe (although the
#. .I race
#. mark under AS-Unsafe will be omitted
#. as redundant with the one under MT-Unsafe).
#. As in the case of user-exposed objects,
#. the mark may be followed by a colon and an identifier.
#. The identifier groups all functions that operate on a
#. certain unguarded object; users may avoid the MT-Safety issues related
#. with unguarded concurrent access to such internal objects by creating a
#. non-recursive mutex related with the identifier,
#. and always holding the mutex when calling any function marked
#. as racy on that identifier,
#. as they would have to should the identifier be
#. an object under user control.
#. The non-recursive mutex avoids the MT-Safety issue,
#. but it trades one AS-Safety issue for another,
#. so use in asynchronous signals remains undefined.
#. When the identifier relates to a static buffer used to hold return values,
#. the mutex must be held for as long as the buffer remains in use
#. by the caller.
#. Many functions that return pointers to static buffers offer reentrant
#. variants that store return values in caller-supplied buffers instead.
#. In some cases, such as
#. .BR tmpname (3),
#. the variant is chosen not by calling an alternate entry point,
#. but by passing a non-NULL pointer to the buffer in which the
#. returned values are to be stored.
#. These variants are generally preferable in multi-threaded programs,
#. although some of them are not MT-Safe because of other internal buffers,
#. also documented with
#. .I race
#. notes.
#. type: Plain text
#. #-#-#-#-# opensuse-leap-15-6: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. We consider access to objects passed as (indirect) arguments to
#. functions to be data race free.
#. The assurance of data race free objects
#. is the caller's responsibility.
#. We will not mark a function as MT-Unsafe or AS-Unsafe
#. if it misbehaves when users fail to take the measures required by
#. POSIX to avoid data races when dealing with such objects.
#. As a general rule, if a function is documented as reading from
#. an object passed (by reference) to it, or modifying it,
#. users ought to use memory synchronization primitives
#. to avoid data races just as they would should they perform
#. the accesses themselves rather than by calling the library function.
#. Standard I/O
#. .RI ( "FILE *" )
#. streams are the exception to the general rule,
#. in that POSIX mandates the library to guard against data races
#. in many functions that manipulate objects of this specific opaque type.
#. We regard this as a convenience provided to users,
#. rather than as a general requirement whose expectations
#. should extend to other types.
#. In order to remind users that guarding certain arguments is their
#. responsibility, we will annotate functions that take objects of certain
#. types as arguments.
#. We draw the line for objects passed by users as follows:
#. objects whose types are exposed to users,
#. and that users are expected to access directly,
#. such as memory buffers, strings,
#. and various user-visible structured types, do
#. .I not
#. give reason for functions to be annotated with
#. .IR race .
#. It would be noisy and redundant with the general requirement,
#. and not many would be surprised by the library's lack of internal
#. guards when accessing objects that can be accessed directly by users.
#. As for objects that are opaque or opaque-like,
#. in that they are to be manipulated only by passing them
#. to library functions (e.g.,
#. .IR FILE ,
#. .IR DIR ,
#. .IR obstack ,
#. .IR iconv_t ),
#. there might be additional expectations as to internal coordination
#. of access by the library.
#. We will annotate, with
#. .I race
#. followed by a colon and the argument name,
#. functions that take such objects but that do not take
#. care of synchronizing access to them by default.
#. For example,
#. .I FILE
#. stream
#. .I unlocked
#. functions
#. .RB ( unlocked_stdio (3))
#. will be annotated,
#. but those that perform implicit locking on
#. .I FILE
#. streams by default will not,
#. even though the implicit locking may be disabled on a per-stream basis.
#. In either case, we will not regard as MT-Unsafe functions that may
#. access user-supplied objects in unsafe ways should users fail to ensure
#. the accesses are well defined.
#. The notion prevails that users are expected to safeguard against
#. data races any user-supplied objects that the library accesses
#. on their behalf.
#. .\" The above describes @mtsrace; @mtasurace is described below.
#. This user responsibility does not apply, however,
#. to objects controlled by the library itself,
#. such as internal objects and static buffers used
#. to return values from certain calls.
#. When the library doesn't guard them against concurrent uses,
#. these cases are regarded as MT-Unsafe and AS-Unsafe (although the
#. .I race
#. mark under AS-Unsafe will be omitted
#. as redundant with the one under MT-Unsafe).
#. As in the case of user-exposed objects,
#. the mark may be followed by a colon and an identifier.
#. The identifier groups all functions that operate on a
#. certain unguarded object; users may avoid the MT-Safety issues related
#. with unguarded concurrent access to such internal objects by creating a
#. non-recursive mutex related with the identifier,
#. and always holding the mutex when calling any function marked
#. as racy on that identifier,
#. as they would have to should the identifier be
#. an object under user control.
#. The non-recursive mutex avoids the MT-Safety issue,
#. but it trades one AS-Safety issue for another,
#. so use in asynchronous signals remains undefined.
#. When the identifier relates to a static buffer used to hold return values,
#. the mutex must be held for as long as the buffer remains in use
#. by the caller.
#. Many functions that return pointers to static buffers offer reentrant
#. variants that store return values in caller-supplied buffers instead.
#. In some cases, such as
#. .BR tmpname (3),
#. the variant is chosen not by calling an alternate entry point,
#. but by passing a non-NULL pointer to the buffer in which the
#. returned values are to be stored.
#. These variants are generally preferable in multi-threaded programs,
#. although some of them are not MT-Safe because of other internal buffers,
#. also documented with
#. .I race
#. notes.
#. type: Plain text
#. #-#-#-#-# opensuse-tumbleweed: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. We consider access to objects passed as (indirect) arguments to
#. functions to be data race free.
#. The assurance of data race free objects
#. is the caller's responsibility.
#. We will not mark a function as MT-Unsafe or AS-Unsafe
#. if it misbehaves when users fail to take the measures required by
#. POSIX to avoid data races when dealing with such objects.
#. As a general rule, if a function is documented as reading from
#. an object passed (by reference) to it, or modifying it,
#. users ought to use memory synchronization primitives
#. to avoid data races just as they would should they perform
#. the accesses themselves rather than by calling the library function.
#. Standard I/O
#. .RI ( "FILE *" )
#. streams are the exception to the general rule,
#. in that POSIX mandates the library to guard against data races
#. in many functions that manipulate objects of this specific opaque type.
#. We regard this as a convenience provided to users,
#. rather than as a general requirement whose expectations
#. should extend to other types.
#. In order to remind users that guarding certain arguments is their
#. responsibility, we will annotate functions that take objects of certain
#. types as arguments.
#. We draw the line for objects passed by users as follows:
#. objects whose types are exposed to users,
#. and that users are expected to access directly,
#. such as memory buffers, strings,
#. and various user-visible structured types, do
#. .I not
#. give reason for functions to be annotated with
#. .IR race .
#. It would be noisy and redundant with the general requirement,
#. and not many would be surprised by the library's lack of internal
#. guards when accessing objects that can be accessed directly by users.
#. As for objects that are opaque or opaque-like,
#. in that they are to be manipulated only by passing them
#. to library functions (e.g.,
#. .IR FILE ,
#. .IR DIR ,
#. .IR obstack ,
#. .IR iconv_t ),
#. there might be additional expectations as to internal coordination
#. of access by the library.
#. We will annotate, with
#. .I race
#. followed by a colon and the argument name,
#. functions that take such objects but that do not take
#. care of synchronizing access to them by default.
#. For example,
#. .I FILE
#. stream
#. .I unlocked
#. functions
#. .RB ( unlocked_stdio (3))
#. will be annotated,
#. but those that perform implicit locking on
#. .I FILE
#. streams by default will not,
#. even though the implicit locking may be disabled on a per-stream basis.
#. In either case, we will not regard as MT-Unsafe functions that may
#. access user-supplied objects in unsafe ways should users fail to ensure
#. the accesses are well defined.
#. The notion prevails that users are expected to safeguard against
#. data races any user-supplied objects that the library accesses
#. on their behalf.
#. .\" The above describes @mtsrace; @mtasurace is described below.
#. This user responsibility does not apply, however,
#. to objects controlled by the library itself,
#. such as internal objects and static buffers used
#. to return values from certain calls.
#. When the library doesn't guard them against concurrent uses,
#. these cases are regarded as MT-Unsafe and AS-Unsafe (although the
#. .I race
#. mark under AS-Unsafe will be omitted
#. as redundant with the one under MT-Unsafe).
#. As in the case of user-exposed objects,
#. the mark may be followed by a colon and an identifier.
#. The identifier groups all functions that operate on a
#. certain unguarded object; users may avoid the MT-Safety issues related
#. with unguarded concurrent access to such internal objects by creating a
#. non-recursive mutex related with the identifier,
#. and always holding the mutex when calling any function marked
#. as racy on that identifier,
#. as they would have to should the identifier be
#. an object under user control.
#. The non-recursive mutex avoids the MT-Safety issue,
#. but it trades one AS-Safety issue for another,
#. so use in asynchronous signals remains undefined.
#. When the identifier relates to a static buffer used to hold return values,
#. the mutex must be held for as long as the buffer remains in use
#. by the caller.
#. Many functions that return pointers to static buffers offer reentrant
#. variants that store return values in caller-supplied buffers instead.
#. In some cases, such as
#. .BR tmpname (3),
#. the variant is chosen not by calling an alternate entry point,
#. but by passing a non-NULL pointer to the buffer in which the
#. returned values are to be stored.
#. These variants are generally preferable in multi-threaded programs,
#. although some of them are not MT-Safe because of other internal buffers,
#. also documented with
#. .I race
#. notes.
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"Functions annotated with I<race> as an MT-Safety issue operate on objects in "
"ways that may cause data races or similar forms of destructive interference "
"out of concurrent execution. In some cases, the objects are passed to the "
"functions by users; in others, they are used by the functions to return "
"values to users; in others, they are not even exposed to users."
msgstr ""
"Mit I<race> als MT-Safety-Problem kommentierte Funktionen agieren auf "
"Objekten derart, dass Ressourcenwettläufe auf Daten oder ähnliche Formen "
"desktruktiven Störens bei nebenläufiger Ausführung ausgelöst werden. In "
"einigen Fällen werden die Objekte durch Benutzer an die Funktionen "
"übergeben. In anderen Fällen werden sie von den Funktionen verwandt, um "
"Werte an Benutzer zurückzugeben. In wieder anderen werden sie noch nicht mal "
"gegenüber Benutzern offengelegt."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I<const>"
msgstr "I<const>"
#. and AS-Unsafe,
#. equally
#. and AS-Unsafe
#. and AS-Safe
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"Functions marked with I<const> as an MT-Safety issue non-atomically modify "
"internal objects that are better regarded as constant, because a substantial "
"portion of the GNU C Library accesses them without synchronization. Unlike "
"I<race>, which causes both readers and writers of internal objects to be "
"regarded as MT-Unsafe, this mark is applied to writers only. Writers remain "
"MT-Unsafe to call, but the then-mandatory constness of objects they modify "
"enables readers to be regarded as MT-Safe (as long as no other reasons for "
"them to be unsafe remain), since the lack of synchronization is not a "
"problem when the objects are effectively constant."
msgstr ""
"Mit I<const> als MT-Safety-Problem markierte Funktionen verändern interne "
"Objekte nicht atomar, die besser als konstant betrachtet werden, da ein "
"wesentlicher Anteil der GNU-C-Bibliothek auf sie ohne Synchronisierung "
"zugreift. Anders als bei I<race>, bei dem sowohl schreibende als auch "
"lesende Zugriffe auf interne Objekte als MT-Unsafe betrachtet werden, gilt "
"diese Markierung nur für schreibende Zugriffe. Bei schreibenden Zugriffen "
"bleibt der Aufruf MT-Unsafe, aber die dann-verpflichtende Konstantheit von "
"Objekten, die sie verändern, ermöglicht es MT-Safe lesenden Zugriff (solange "
"es kein anderer Grund verbleibt, sie als unsicher zu betrachten), da das "
"Fehlen von Synchronisierung kein Problem darstellt, wenn die Objekte "
"tatsächlich konstant sind."
#
#. The non-recursive locking removes the MT-Safety problem,
#. but it trades one AS-Safety problem for another,
#. so use in asynchronous signals remains undefined.
#. .\" But what if, instead of marking modifiers with const:id and readers
#. .\" with just id, we marked writers with race:id and readers with ro:id?
#. .\" Instead of having to define each instance of 'id', we'd have a
#. .\" general pattern governing all such 'id's, wherein race:id would
#. .\" suggest the need for an exclusive/write lock to make the function
#. .\" safe, whereas ro:id would indicate 'id' is expected to be read-only,
#. .\" but if any modifiers are called (while holding an exclusive lock),
#. .\" then ro:id-marked functions ought to be guarded with a read lock for
#. .\" safe operation. ro:env or ro:locale, for example, seems to convey
#. .\" more clearly the expectations and the meaning, than just env or
#. .\" locale.
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"The identifier that follows the I<const> mark will appear by itself as a "
"safety note in readers. Programs that wish to work around this safety "
"issue, so as to call writers, may use a non-recursive read-write lock "
"associated with the identifier, and guard I<all> calls to functions marked "
"with I<const> followed by the identifier with a write lock, and I<all> calls "
"to functions marked with the identifier by itself with a read lock."
msgstr ""
"Der Markierung I<const> folgende Kennzeichner taucht selbst als "
"Sicherheitshinweis für Lesezugriffe auf. Programme, die dieses "
"Sicherheitsproblem umgehen möchten, um Schreibzugriff durchzuführen, können "
"eine dem Kennzeichner zugeordnete nicht rekursive Lese-Schreib-Sperre "
"verwenden und I<alle> Aufrufe von mit I<const> gefolgt von dem Kennzeichner "
"markierten Funktionen mit einer Schreibsperre und I<alle> Aufrufe von mit "
"dem Kennzeichner selbst markierten Funktionen mit einer Lesesperre absichern."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I<sig>"
msgstr "I<sig>"
#. (that implies an identical AS-Safety issue, omitted for brevity)
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"Functions marked with I<sig> as a MT-Safety issue may temporarily install a "
"signal handler for internal purposes, which may interfere with other uses of "
"the signal, identified after a colon."
msgstr ""
"Mit I<sig> als MT-Safety-Problem markierte Funktionen können temporär einen "
"Signal-Handhaber für interne Zwecke installieren, der mit anderen "
"Verwendungen des Signals wechselwirkt, die nach einem Doppelpunkt "
"dargestellt sind."
#
#
#
#. There is no safe way to guarantee the original signal handler is
#. restored in case of asynchronous cancelation,
#. therefore so-marked functions are also AC-Unsafe.
#. .\" fixme: at least deferred cancelation should get it right, and would
#. .\" obviate the restoring bit below, and the qualifier above.
#. Besides the measures recommended to work around the
#. MT-Safety and AS-Safety problem,
#. in order to avert the cancelation problem,
#. disabling asynchronous cancelation
#. .I and
#. installing a cleanup handler to restore the signal to the desired state
#. and to release the mutex are recommended.
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"This safety problem can be worked around by ensuring that no other uses of "
"the signal will take place for the duration of the call. Holding a non-"
"recursive mutex while calling all functions that use the same temporary "
"signal; blocking that signal before the call and resetting its handler "
"afterwards is recommended."
msgstr ""
"Dieses Sicherheitsproblem kann umgangen werden, indem sichergestellt wird, "
"dass während der Dauer des Aufrufs keine andere Verwendung dieses Signals "
"stattfindet. Es wird empfohlen, einen nicht rekursiven Mutex beim Aufruf "
"aller Funktionen, die das gleiche temporäre Signal verwenden, zu halten und "
"das Signal vor dem Aufruf zu blockieren und seinen Handhaber danach "
"zurückzusetzen."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I<term>"
msgstr "I<term>"
#. The same window enables changes made by asynchronous signals to be lost.
#. These functions are also AS-Unsafe,
#. but the corresponding mark is omitted as redundant.
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"Functions marked with I<term> as an MT-Safety issue may change the terminal "
"settings in the recommended way, namely: call B<tcgetattr>(3), modify some "
"flags, and then call B<tcsetattr>(3), this creates a window in which changes "
"made by other threads are lost. Thus, functions marked with I<term> are MT-"
"Unsafe."
msgstr ""
"Mit I<term> als MT-Safety-Problem markierte Funktionen können ihre "
"Terminaleinstellungen auf die empfohlene Art ändern, konkret: "
"B<tcgetattr>(3) aufrufen, einige Schalter ändern und dann B<tcsetattr>(3) "
"aufrufen. Dadurch entsteht ein Fenster, in dem einige durch andere Threads "
"vorgenommene Änderungen verloren gehen. Daher sind mit I<term> markierte "
"Funktionen MT-Unsafe."
#
#
#
#. Functions marked with
#. .I term
#. as an AC-Safety issue are supposed to
#. restore terminal settings to their original state,
#. after temporarily changing them, but they may fail to do so if canceled.
#. .\" fixme: at least deferred cancelation should get it right, and would
#. .\" obviate the restoring bit below, and the qualifier above.
#. Besides the measures recommended to work around the
#. MT-Safety and AS-Safety problem,
#. in order to avert the cancelation problem,
#. disabling asynchronous cancelation
#. .I and
#. installing a cleanup handler to
#. restore the terminal settings to the original state and to release the
#. mutex are recommended.
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"It is thus advisable for applications using the terminal to avoid concurrent "
"and reentrant interactions with it, by not using it in signal handlers or "
"blocking signals that might use it, and holding a lock while calling these "
"functions and interacting with the terminal. This lock should also be used "
"for mutual exclusion with functions marked with I<race:tcattr(fd)>, where "
"I<fd> is a file descriptor for the controlling terminal. The caller may use "
"a single mutex for simplicity, or use one mutex per terminal, even if "
"referenced by different file descriptors."
msgstr ""
"Für Anwendungen, die das Terminal verwenden, wird daher empfohlen, "
"nebenläufige oder wiedereintrittsfähige Interaktionen damit zu vermeiden, "
"indem keine Signal-Handhaber verwandt oder Signale, die es verwenden könnte, "
"blockiert werden und eine Sperre gehalten wird, während diese Funktionen "
"aufgerufen und mit dem Terminal interagiert wird. Diese Sperre sollte auch "
"zum gegenseitigen Ausschluss von mit I<race:tcattr(dd)> markierten "
"Funktionen verwandt werden, wo I<dd> ein Dateideskriptor für das steuernde "
"Terminal ist. Das aufrufende Programm kann zur Vereinfachung einen einzelnen "
"Mutex oder einen Mutex pro Terminal verwenden, selbst wenn die Referenz von "
"verschiedenen Dateideskriptoren kommt."
#. type: SS
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "Other safety remarks"
msgstr "Andere Sicherheitsbemerkungen"
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"Additional keywords may be attached to functions, indicating features that "
"do not make a function unsafe to call, but that may need to be taken into "
"account in certain classes of programs:"
msgstr ""
"An Funktionen können zusätzliche Schlüsselwörter angehängt werden, die "
"Funktionalitäten andeuten, die nicht zum unsicheren Aufruf einer Funktion "
"führen, aber die in bestimmten Klassen von Programmen berücksichtigt werden "
"können müssten:"
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I<locale>"
msgstr "I<locale>"
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"Functions annotated with I<locale> as an MT-Safety issue read from the "
"locale object without any form of synchronization. Functions annotated with "
"I<locale> called concurrently with locale changes may behave in ways that do "
"not correspond to any of the locales active during their execution, but an "
"unpredictable mix thereof."
msgstr ""
"Mit I<locale> als MT-Safety-Problem kommentierte Funktionen lesen von "
"lokalen Objekten ohne irgendeine Form der Synchronisierung. Werden mit "
"I<locale> kommentierte Funktionen gleichzeitig zu lokalen Änderungen "
"aufgerufen, könnte sich deren Verhalten so ändern, dass es nicht den lokalen "
"Werten entspricht, die während ihrer Ausführung aktiv war, sondern einer "
"nicht vorhersagbaren Mischung daraus."
#. or AS-Unsafe,
#. Should the locking strategy suggested under @code{const} be used,
#. failure to guard locale uses is not as fatal as data races in
#. general: unguarded uses will @emph{not} follow dangling pointers or
#. access uninitialized, unmapped or recycled memory. Each access will
#. read from a consistent locale object that is or was active at some
#. point during its execution. Without synchronization, however, it
#. cannot even be assumed that, after a change in locale, earlier
#. locales will no longer be used, even after the newly-chosen one is
#. used in the thread. Nevertheless, even though unguarded reads from
#. the locale will not violate type safety, functions that access the
#. locale multiple times may invoke all sorts of undefined behavior
#. because of the unexpected locale changes.
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"We do not mark these functions as MT-Unsafe, however, because functions that "
"modify the locale object are marked with I<const:locale> and regarded as "
"unsafe. Being unsafe, the latter are not to be called when multiple threads "
"are running or asynchronous signals are enabled, and so the locale can be "
"considered effectively constant in these contexts, which makes the former "
"safe."
msgstr ""
"Diese Funktionen sind allerdings nicht als MT-Unsafe markiert, da "
"Funktionen, die lokale Objekte verändern, als I<const:locale> markiert sind "
"und als unsicher betrachtet werden. Da sie unsicher sind, werden letztere "
"nicht aufgerufen, wenn mehrere Threads laufen oder asynchrone Signale "
"aktiviert sind, und daher die lokalen Objekte tatsächlich in diesen "
"Kontexten als konstant betrachtet werden können, wodurch erstere sicher sind."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I<env>"
msgstr "I<env>"
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"Functions marked with I<env> as an MT-Safety issue access the environment "
"with B<getenv>(3) or similar, without any guards to ensure safety in the "
"presence of concurrent modifications."
msgstr ""
"Mit I<env> als MT-Safety-Problem kommentierte Funktionen greifen auf die "
"Umgebung mit B<getenv>(3) oder ähnlichem zu, ohne jeglichen Schutz, um "
"Sicherheit in der Anwesenheit von nebenläufigen Veränderungen "
"sicherzustellen."
#. or AS-Unsafe,
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"We do not mark these functions as MT-Unsafe, however, because functions that "
"modify the environment are all marked with I<const:env> and regarded as "
"unsafe. Being unsafe, the latter are not to be called when multiple threads "
"are running or asynchronous signals are enabled, and so the environment can "
"be considered effectively constant in these contexts, which makes the former "
"safe."
msgstr ""
"Diese Funktionen sind allerdings nicht als MT-Unsafe markiert, da "
"Funktionen, die die Umgebung verändern, alle mit I<const:env> markiert sind "
"und als unsicher betrachtet werden. Da sie unsicher sind, werden letztere "
"nicht aufgerufen, wenn mehrere Threads laufen oder asynchrone Signale "
"aktiviert sind, und daher die Umgebung tatsächlich in diesen Kontexten als "
"konstant betrachtet werden können, wodurch erstere sicher sind."
Attachment:
signature.asc
Description: PGP signature