# French translation of manpages
# This file is distributed under the same license as the manpages-l10n package.
# Copyright © of this file:
# Christophe Blaess , 1996-2003.
# Stéphan Rafin , 2002.
# Thierry Vignaud , 1999, 2002.
# François Micaux, 2002.
# Alain Portal , 2003-2008.
# Jean-Philippe Guérard , 2005-2006.
# Jean-Luc Coulon (f5ibh) , 2006-2007.
# Julien Cristau , 2006-2007.
# Thomas Huriaux , 2006-2008.
# Nicolas François , 2006-2008.
# Florentin Duneau , 2006-2010.
# Simon Paillard , 2006.
# Denis Barbier , 2006, 2010.
# David Prévot , 2010, 2012.
# Jean-Pierre Giraud , 2021-2023.
msgid ""
msgstr ""
"Project-Id-Version: perkamon\n"
"POT-Creation-Date: 2024-06-01 05:42+0200\n"
"PO-Revision-Date: 2023-06-16 17:20+0200\n"
"Last-Translator: Jean-Pierre Giraud \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Lokalize 20.12.0\n"
#. type: TH
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "attributes"
msgstr "attributes"
#. type: TH
#: archlinux debian-unstable opensuse-tumbleweed
#, no-wrap
msgid "2024-05-02"
msgstr "2 mai 2024"
#. type: TH
#: archlinux debian-unstable
#, no-wrap
msgid "Linux man-pages 6.8"
msgstr "Pages du manuel de Linux 6.8"
#. type: SH
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "NAME"
msgstr "NOM"
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid "attributes - POSIX safety concepts"
msgstr "attributes – Concepts de sécurité POSIX"
#. type: SH
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "DESCRIPTION"
msgstr "DESCRIPTION"
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"I: the text of this man page is based on the material taken from the "
"\"POSIX Safety Concepts\" section of the GNU C Library manual. Further "
"details on the topics described here can be found in that manual."
msgstr ""
"I : le texte de cette page de manuel est basée sur des éléments pris "
"dans la section « POSIX Safety Concepts » du manuel de la bibliothèque "
"GNU C. Plus de détails sur les sujets décrits ici peuvent être trouvés dans "
"ce manuel."
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"Various function manual pages include a section ATTRIBUTES that describes "
"the safety of calling the function in various contexts. This section "
"annotates functions with the following safety markings:"
msgstr ""
"Diverses pages de manuel de fonctions comportent une section ATTRIBUTES qui "
"décrit la sécurité de l'appel d'une fonction dans divers contextes. Cette "
"section annote les fonctions avec les balises de sécurité suivantes :"
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I"
msgstr "I"
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"I or Thread-Safe functions are safe to call in the presence of "
"other threads. MT, in MT-Safe, stands for Multi Thread."
msgstr ""
"Les fonctions I ou I sont sûres à appeler en présence "
"d'autres threads. MT, dans MT-Safe, signifie « multithread »."
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"Being MT-Safe does not imply a function is atomic, nor that it uses any of "
"the memory synchronization mechanisms POSIX exposes to users. It is even "
"possible that calling MT-Safe functions in sequence does not yield an MT-"
"Safe combination. For example, having a thread call two MT-Safe functions "
"one right after the other does not guarantee behavior equivalent to atomic "
"execution of a combination of both functions, since concurrent calls in "
"other threads may interfere in a destructive way."
msgstr ""
"L'état MT-Safe n'implique pas qu'une fonction est atomique, ni qu'elle "
"utilise un des mécanismes de synchronisation de mémoire que POSIX expose aux "
"utilisateurs. Il est même possible que l'appel de plusieurs fonctions MT-"
"Safe à la suite ne produise pas une combinaison MT-Safe. Par exemple, le "
"fait qu'un thread appelle deux fonctions MT-Safe l'une immédiatement après "
"l'autre ne garantit pas un comportement équivalent à l'exécution atomique de "
"la combinaison des deux fonctions, dans la mesure où des appels concomitants "
"dans d'autres threads peuvent interférer de manière destructive."
#
#
#
#. #-#-#-#-# archlinux: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. .TP
#. .I AS-Safe
#. .I AS-Safe
#. or Async-Signal-Safe functions are safe to call from
#. asynchronous signal handlers.
#. AS, in AS-Safe, stands for Asynchronous Signal.
#. Many functions that are AS-Safe may set
#. .IR errno ,
#. or modify the floating-point environment,
#. because their doing so does not make them
#. unsuitable for use in signal handlers.
#. However, programs could misbehave should asynchronous signal handlers
#. modify this thread-local state,
#. and the signal handling machinery cannot be counted on to
#. preserve it.
#. Therefore, signal handlers that call functions that may set
#. .I errno
#. or modify the floating-point environment
#. .I must
#. save their original values, and restore them before returning.
#. .TP
#. .I AC-Safe
#. .I AC-Safe
#. or Async-Cancel-Safe functions are safe to call when
#. asynchronous cancelation is enabled.
#. AC in AC-Safe stands for Asynchronous Cancelation.
#. The POSIX standard defines only three functions to be AC-Safe, namely
#. .BR pthread_cancel (3),
#. .BR pthread_setcancelstate (3),
#. and
#. .BR pthread_setcanceltype (3).
#. At present the GNU C Library provides no
#. guarantees beyond these three functions,
#. but does document which functions are presently AC-Safe.
#. This documentation is provided for use
#. by the GNU C Library developers.
#. Just like signal handlers, cancelation cleanup routines must configure
#. the floating point environment they require.
#. The routines cannot assume a floating point environment,
#. particularly when asynchronous cancelation is enabled.
#. If the configuration of the floating point
#. environment cannot be performed atomically then it is also possible that
#. the environment encountered is internally inconsistent.
#. type: Plain text
#. #-#-#-#-# debian-bookworm: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. .TP
#. .I AS-Safe
#. .I AS-Safe
#. or Async-Signal-Safe functions are safe to call from
#. asynchronous signal handlers.
#. AS, in AS-Safe, stands for Asynchronous Signal.
#. Many functions that are AS-Safe may set
#. .IR errno ,
#. or modify the floating-point environment,
#. because their doing so does not make them
#. unsuitable for use in signal handlers.
#. However, programs could misbehave should asynchronous signal handlers
#. modify this thread-local state,
#. and the signal handling machinery cannot be counted on to
#. preserve it.
#. Therefore, signal handlers that call functions that may set
#. .I errno
#. or modify the floating-point environment
#. .I must
#. save their original values, and restore them before returning.
#. .TP
#. .I AC-Safe
#. .I AC-Safe
#. or Async-Cancel-Safe functions are safe to call when
#. asynchronous cancelation is enabled.
#. AC in AC-Safe stands for Asynchronous Cancellation.
#. The POSIX standard defines only three functions to be AC-Safe, namely
#. .BR pthread_cancel (3),
#. .BR pthread_setcancelstate (3),
#. and
#. .BR pthread_setcanceltype (3).
#. At present the GNU C Library provides no
#. guarantees beyond these three functions,
#. but does document which functions are presently AC-Safe.
#. This documentation is provided for use
#. by the GNU C Library developers.
#. Just like signal handlers, cancelation cleanup routines must configure
#. the floating point environment they require.
#. The routines cannot assume a floating point environment,
#. particularly when asynchronous cancelation is enabled.
#. If the configuration of the floating point
#. environment cannot be performed atomically then it is also possible that
#. the environment encountered is internally inconsistent.
#. type: Plain text
#. #-#-#-#-# debian-unstable: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. .TP
#. .I AS-Safe
#. .I AS-Safe
#. or Async-Signal-Safe functions are safe to call from
#. asynchronous signal handlers.
#. AS, in AS-Safe, stands for Asynchronous Signal.
#. Many functions that are AS-Safe may set
#. .IR errno ,
#. or modify the floating-point environment,
#. because their doing so does not make them
#. unsuitable for use in signal handlers.
#. However, programs could misbehave should asynchronous signal handlers
#. modify this thread-local state,
#. and the signal handling machinery cannot be counted on to
#. preserve it.
#. Therefore, signal handlers that call functions that may set
#. .I errno
#. or modify the floating-point environment
#. .I must
#. save their original values, and restore them before returning.
#. .TP
#. .I AC-Safe
#. .I AC-Safe
#. or Async-Cancel-Safe functions are safe to call when
#. asynchronous cancelation is enabled.
#. AC in AC-Safe stands for Asynchronous Cancelation.
#. The POSIX standard defines only three functions to be AC-Safe, namely
#. .BR pthread_cancel (3),
#. .BR pthread_setcancelstate (3),
#. and
#. .BR pthread_setcanceltype (3).
#. At present the GNU C Library provides no
#. guarantees beyond these three functions,
#. but does document which functions are presently AC-Safe.
#. This documentation is provided for use
#. by the GNU C Library developers.
#. Just like signal handlers, cancelation cleanup routines must configure
#. the floating point environment they require.
#. The routines cannot assume a floating point environment,
#. particularly when asynchronous cancelation is enabled.
#. If the configuration of the floating point
#. environment cannot be performed atomically then it is also possible that
#. the environment encountered is internally inconsistent.
#. type: Plain text
#. #-#-#-#-# fedora-40: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. .TP
#. .I AS-Safe
#. .I AS-Safe
#. or Async-Signal-Safe functions are safe to call from
#. asynchronous signal handlers.
#. AS, in AS-Safe, stands for Asynchronous Signal.
#. Many functions that are AS-Safe may set
#. .IR errno ,
#. or modify the floating-point environment,
#. because their doing so does not make them
#. unsuitable for use in signal handlers.
#. However, programs could misbehave should asynchronous signal handlers
#. modify this thread-local state,
#. and the signal handling machinery cannot be counted on to
#. preserve it.
#. Therefore, signal handlers that call functions that may set
#. .I errno
#. or modify the floating-point environment
#. .I must
#. save their original values, and restore them before returning.
#. .TP
#. .I AC-Safe
#. .I AC-Safe
#. or Async-Cancel-Safe functions are safe to call when
#. asynchronous cancelation is enabled.
#. AC in AC-Safe stands for Asynchronous Cancelation.
#. The POSIX standard defines only three functions to be AC-Safe, namely
#. .BR pthread_cancel (3),
#. .BR pthread_setcancelstate (3),
#. and
#. .BR pthread_setcanceltype (3).
#. At present the GNU C Library provides no
#. guarantees beyond these three functions,
#. but does document which functions are presently AC-Safe.
#. This documentation is provided for use
#. by the GNU C Library developers.
#. Just like signal handlers, cancelation cleanup routines must configure
#. the floating point environment they require.
#. The routines cannot assume a floating point environment,
#. particularly when asynchronous cancelation is enabled.
#. If the configuration of the floating point
#. environment cannot be performed atomically then it is also possible that
#. the environment encountered is internally inconsistent.
#. type: Plain text
#. #-#-#-#-# fedora-rawhide: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. .TP
#. .I AS-Safe
#. .I AS-Safe
#. or Async-Signal-Safe functions are safe to call from
#. asynchronous signal handlers.
#. AS, in AS-Safe, stands for Asynchronous Signal.
#. Many functions that are AS-Safe may set
#. .IR errno ,
#. or modify the floating-point environment,
#. because their doing so does not make them
#. unsuitable for use in signal handlers.
#. However, programs could misbehave should asynchronous signal handlers
#. modify this thread-local state,
#. and the signal handling machinery cannot be counted on to
#. preserve it.
#. Therefore, signal handlers that call functions that may set
#. .I errno
#. or modify the floating-point environment
#. .I must
#. save their original values, and restore them before returning.
#. .TP
#. .I AC-Safe
#. .I AC-Safe
#. or Async-Cancel-Safe functions are safe to call when
#. asynchronous cancelation is enabled.
#. AC in AC-Safe stands for Asynchronous Cancelation.
#. The POSIX standard defines only three functions to be AC-Safe, namely
#. .BR pthread_cancel (3),
#. .BR pthread_setcancelstate (3),
#. and
#. .BR pthread_setcanceltype (3).
#. At present the GNU C Library provides no
#. guarantees beyond these three functions,
#. but does document which functions are presently AC-Safe.
#. This documentation is provided for use
#. by the GNU C Library developers.
#. Just like signal handlers, cancelation cleanup routines must configure
#. the floating point environment they require.
#. The routines cannot assume a floating point environment,
#. particularly when asynchronous cancelation is enabled.
#. If the configuration of the floating point
#. environment cannot be performed atomically then it is also possible that
#. the environment encountered is internally inconsistent.
#. type: Plain text
#. #-#-#-#-# mageia-cauldron: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. .TP
#. .I AS-Safe
#. .I AS-Safe
#. or Async-Signal-Safe functions are safe to call from
#. asynchronous signal handlers.
#. AS, in AS-Safe, stands for Asynchronous Signal.
#. Many functions that are AS-Safe may set
#. .IR errno ,
#. or modify the floating-point environment,
#. because their doing so does not make them
#. unsuitable for use in signal handlers.
#. However, programs could misbehave should asynchronous signal handlers
#. modify this thread-local state,
#. and the signal handling machinery cannot be counted on to
#. preserve it.
#. Therefore, signal handlers that call functions that may set
#. .I errno
#. or modify the floating-point environment
#. .I must
#. save their original values, and restore them before returning.
#. .TP
#. .I AC-Safe
#. .I AC-Safe
#. or Async-Cancel-Safe functions are safe to call when
#. asynchronous cancelation is enabled.
#. AC in AC-Safe stands for Asynchronous Cancelation.
#. The POSIX standard defines only three functions to be AC-Safe, namely
#. .BR pthread_cancel (3),
#. .BR pthread_setcancelstate (3),
#. and
#. .BR pthread_setcanceltype (3).
#. At present the GNU C Library provides no
#. guarantees beyond these three functions,
#. but does document which functions are presently AC-Safe.
#. This documentation is provided for use
#. by the GNU C Library developers.
#. Just like signal handlers, cancelation cleanup routines must configure
#. the floating point environment they require.
#. The routines cannot assume a floating point environment,
#. particularly when asynchronous cancelation is enabled.
#. If the configuration of the floating point
#. environment cannot be performed atomically then it is also possible that
#. the environment encountered is internally inconsistent.
#. type: Plain text
#. #-#-#-#-# opensuse-leap-15-6: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. .TP
#. .I AS-Safe
#. .I AS-Safe
#. or Async-Signal-Safe functions are safe to call from
#. asynchronous signal handlers.
#. AS, in AS-Safe, stands for Asynchronous Signal.
#. Many functions that are AS-Safe may set
#. .IR errno ,
#. or modify the floating-point environment,
#. because their doing so does not make them
#. unsuitable for use in signal handlers.
#. However, programs could misbehave should asynchronous signal handlers
#. modify this thread-local state,
#. and the signal handling machinery cannot be counted on to
#. preserve it.
#. Therefore, signal handlers that call functions that may set
#. .I errno
#. or modify the floating-point environment
#. .I must
#. save their original values, and restore them before returning.
#. .TP
#. .I AC-Safe
#. .I AC-Safe
#. or Async-Cancel-Safe functions are safe to call when
#. asynchronous cancelation is enabled.
#. AC in AC-Safe stands for Asynchronous Cancelation.
#. The POSIX standard defines only three functions to be AC-Safe, namely
#. .BR pthread_cancel (3),
#. .BR pthread_setcancelstate (3),
#. and
#. .BR pthread_setcanceltype (3).
#. At present the GNU C Library provides no
#. guarantees beyond these three functions,
#. but does document which functions are presently AC-Safe.
#. This documentation is provided for use
#. by the GNU C Library developers.
#. Just like signal handlers, cancelation cleanup routines must configure
#. the floating point environment they require.
#. The routines cannot assume a floating point environment,
#. particularly when asynchronous cancelation is enabled.
#. If the configuration of the floating point
#. environment cannot be performed atomically then it is also possible that
#. the environment encountered is internally inconsistent.
#. type: Plain text
#. #-#-#-#-# opensuse-tumbleweed: attributes.7.pot (PACKAGE VERSION) #-#-#-#-#
#. .TP
#. .I AS-Safe
#. .I AS-Safe
#. or Async-Signal-Safe functions are safe to call from
#. asynchronous signal handlers.
#. AS, in AS-Safe, stands for Asynchronous Signal.
#. Many functions that are AS-Safe may set
#. .IR errno ,
#. or modify the floating-point environment,
#. because their doing so does not make them
#. unsuitable for use in signal handlers.
#. However, programs could misbehave should asynchronous signal handlers
#. modify this thread-local state,
#. and the signal handling machinery cannot be counted on to
#. preserve it.
#. Therefore, signal handlers that call functions that may set
#. .I errno
#. or modify the floating-point environment
#. .I must
#. save their original values, and restore them before returning.
#. .TP
#. .I AC-Safe
#. .I AC-Safe
#. or Async-Cancel-Safe functions are safe to call when
#. asynchronous cancelation is enabled.
#. AC in AC-Safe stands for Asynchronous Cancelation.
#. The POSIX standard defines only three functions to be AC-Safe, namely
#. .BR pthread_cancel (3),
#. .BR pthread_setcancelstate (3),
#. and
#. .BR pthread_setcanceltype (3).
#. At present the GNU C Library provides no
#. guarantees beyond these three functions,
#. but does document which functions are presently AC-Safe.
#. This documentation is provided for use
#. by the GNU C Library developers.
#. Just like signal handlers, cancelation cleanup routines must configure
#. the floating point environment they require.
#. The routines cannot assume a floating point environment,
#. particularly when asynchronous cancelation is enabled.
#. If the configuration of the floating point
#. environment cannot be performed atomically then it is also possible that
#. the environment encountered is internally inconsistent.
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"Whole-program optimizations that could inline functions across library "
"interfaces may expose unsafe reordering, and so performing inlining across "
"the GNU C Library interface is not recommended. The documented MT-Safety "
"status is not guaranteed under whole-program optimization. However, "
"functions defined in user-visible headers are designed to be safe for "
"inlining."
msgstr ""
"Les optimisations à l'échelle du programme qui peuvent intégrer des "
"fonctions à travers les interfaces des bibliothèques peuvent exposer à des "
"réorganisations non sûres, aussi il n'est pas recommandé de réaliser des "
"intégrations au moyen des interfaces de la bibliothèque GNU C. L'état "
"documenté MT-Safety n'est pas garanti. Néanmoins, les fonctions définies "
"dans les en-têtes visibles par l'utilisateur sont conçues pour être sûres "
"pour l'intégration."
#. ", " AS-Unsafe ", " AC-Unsafe
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I"
msgstr "I"
#
#
#
#
#
#
#. ", " AS-Unsafe ", " AC-Unsafe
#. functions are not
#. safe to call within the safety contexts described above.
#. Calling them
#. within such contexts invokes undefined behavior.
#. Functions not explicitly documented as safe in a safety context should
#. be regarded as Unsafe.
#. .TP
#. .I Preliminary
#. .I Preliminary
#. safety properties are documented, indicating these
#. properties may
#. .I not
#. be counted on in future releases of
#. the GNU C Library.
#. Such preliminary properties are the result of an assessment of the
#. properties of our current implementation,
#. rather than of what is mandated and permitted
#. by current and future standards.
#. Although we strive to abide by the standards, in some cases our
#. implementation is safe even when the standard does not demand safety,
#. and in other cases our implementation does not meet the standard safety
#. requirements.
#. The latter are most likely bugs; the former, when marked
#. as
#. .IR Preliminary ,
#. should not be counted on: future standards may
#. require changes that are not compatible with the additional safety
#. properties afforded by the current implementation.
#. Furthermore,
#. the POSIX standard does not offer a detailed definition of safety.
#. We assume that, by "safe to call", POSIX means that,
#. as long as the program does not invoke undefined behavior,
#. the "safe to call" function behaves as specified,
#. and does not cause other functions to deviate from their specified behavior.
#. We have chosen to use its loose
#. definitions of safety, not because they are the best definitions to use,
#. but because choosing them harmonizes this manual with POSIX.
#. Please keep in mind that these are preliminary definitions and annotations,
#. and certain aspects of the definitions are still under
#. discussion and might be subject to clarification or change.
#. Over time,
#. we envision evolving the preliminary safety notes into stable commitments,
#. as stable as those of our interfaces.
#. As we do, we will remove the
#. .I Preliminary
#. keyword from safety notes.
#. As long as the keyword remains, however,
#. they are not to be regarded as a promise of future behavior.
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"I functions are not safe to call in a multithreaded programs."
msgstr ""
"Les fonctions I ne sont pas sûres pour des appels dans des "
"programmes multithreadés."
#
#
#
#
#
#
#
#
#
#
#
#. .SS Unsafe features
#. Functions that are unsafe to call in certain contexts are annotated with
#. keywords that document their features that make them unsafe to call.
#. AS-Unsafe features in this section indicate the functions are never safe
#. to call when asynchronous signals are enabled.
#. AC-Unsafe features
#. indicate they are never safe to call when asynchronous cancelation is
#. .\" enabled.
#. There are no MT-Unsafe marks in this section.
#. .TP
#. .\" .I code
#. Functions marked with
#. .I lock
#. as an AS-Unsafe feature may be
#. .\" interrupted by a signal while holding a non-recursive lock.
#. If the signal handler calls another such function that takes the same lock,
#. the result is a deadlock.
#. Functions annotated with
#. .I lock
#. as an AC-Unsafe feature may, if canceled asynchronously,
#. fail to release a lock that would have been released if their execution
#. had not been interrupted by asynchronous thread cancelation.
#. Once a lock is left taken,
#. attempts to take that lock will block indefinitely.
#. .TP
#. .I corrupt
#. Functions marked with
#. .\" .I corrupt
#. as an AS-Unsafe feature may corrupt
#. data structures and misbehave when they interrupt,
#. or are interrupted by, another such function.
#. Unlike functions marked with
#. .IR lock ,
#. these take recursive locks to avoid MT-Safety problems,
#. but this is not enough to stop a signal handler from observing
#. a partially-updated data structure.
#. Further corruption may arise from the interrupted function's
#. failure to notice updates made by signal handlers.
#. Functions marked with
#. .I corrupt
#. as an AC-Unsafe feature may leave
#. data structures in a corrupt, partially updated state.
#. Subsequent uses of the data structure may misbehave.
#. .\" A special case, probably not worth documenting separately, involves
#. .\" reallocing, or even freeing pointers. Any case involving free could
#. .\" be easily turned into an ac-safe leak by resetting the pointer before
#. .\" releasing it; I don't think we have any case that calls for this sort
#. .\" of fixing. Fixing the realloc cases would require a new interface:
#. .\" instead of @code{ptr=realloc(ptr,size)} we'd have to introduce
#. .\" @code{acsafe_realloc(&ptr,size)} that would modify ptr before
#. .\" releasing the old memory. The ac-unsafe realloc could be implemented
#. .\" in terms of an internal interface with this semantics (say
#. .\" __acsafe_realloc), but since realloc can be overridden, the function
#. .\" we call to implement realloc should not be this internal interface,
#. .\" but another internal interface that calls __acsafe_realloc if realloc
#. .\" was not overridden, and calls the overridden realloc with async
#. .\" cancel disabled. --lxoliva
#. .TP
#. .I heap
#. Functions marked with
#. .I heap
#. may call heap memory management functions from the
#. .BR malloc (3)/ free (3)
#. family of functions and are only as safe as those functions.
#. This note is thus equivalent to:
#. | AS-Unsafe lock | AC-Unsafe lock fd mem |
#. .\" @sampsafety{@asunsafe{@asulock{}}@acunsafe{@aculock{} @acsfd{} @acsmem{}}}
#. .\"
#. .\" Check for cases that should have used plugin instead of or in
#. .\" addition to this. Then, after rechecking gettext, adjust i18n if
#. .\" needed.
#. .TP
#. .I dlopen
#. Functions marked with
#. .I dlopen
#. use the dynamic loader to load
#. shared libraries into the current execution image.
#. This involves opening files, mapping them into memory,
#. allocating additional memory, resolving symbols,
#. applying relocations and more,
#. all of this while holding internal dynamic loader locks.
#. The locks are enough for these functions to be AS-Unsafe and AC-Unsafe,
#. but other issues may arise.
#. At present this is a placeholder for all
#. potential safety issues raised by
#. .BR dlopen (3).
#. .\" dlopen runs init and fini sections of the module; does this mean
#. .\" dlopen always implies plugin?
#. .TP
#. .I plugin
#. Functions annotated with
#. .I plugin
#. may run code from plugins that
#. may be external to the GNU C Library.
#. Such plugin functions are assumed to be
#. MT-Safe, AS-Unsafe and AC-Unsafe.
#. Examples of such plugins are stack unwinding libraries,
#. name service switch (NSS) and character set conversion (iconv) back-ends.
#. Although the plugins mentioned as examples are all brought in by means
#. of dlopen, the
#. .I plugin
#. keyword does not imply any direct
#. involvement of the dynamic loader or the
#. .I libdl
#. interfaces,
#. those are covered by
#. .IR dlopen .
#. For example, if one function loads a module and finds the addresses
#. of some of its functions,
#. while another just calls those already-resolved functions,
#. the former will be marked with
#. .IR dlopen ,
#. whereas the latter will get the
#. .IR plugin .
#. When a single function takes all of these actions, then it gets both marks.
#. .TP
#. .I i18n
#. Functions marked with
#. .I i18n
#. may call internationalization
#. functions of the
#. .BR gettext (3)
#. family and will be only as safe as those
#. functions.
#. This note is thus equivalent to:
#. | MT-Safe env | AS-Unsafe corrupt heap dlopen | AC-Unsafe corrupt |
#. .\" @sampsafety{@mtsafe{@mtsenv{}}@asunsafe{@asucorrupt{} @ascuheap{} @ascudlopen{}}@acunsafe{@acucorrupt{}}}
#. .TP
#. .I timer
#. Functions marked with
#. .I timer
#. use the
#. .BR alarm (3)
#. function or
#. similar to set a time-out for a system call or a long-running operation.
#. In a multi-threaded program, there is a risk that the time-out signal
#. will be delivered to a different thread,
#. thus failing to interrupt the intended thread.
#. Besides being MT-Unsafe, such functions are always
#. AS-Unsafe, because calling them in signal handlers may interfere with
#. timers set in the interrupted code, and AC-Unsafe,
#. because there is no safe way to guarantee an earlier timer
#. will be reset in case of asynchronous cancelation.
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"Other keywords that appear in safety notes are defined in subsequent "
"sections."
msgstr ""
"D'autres mots-clefs qui apparaissent dans des notes de sûreté sont définis "
"dans les sections suivantes."
#. type: SS
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "Conditionally safe features"
msgstr "Fonctionnalités sûres sous condition"
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"For some features that make functions unsafe to call in certain contexts, "
"there are known ways to avoid the safety problem other than refraining from "
"calling the function altogether. The keywords that follow refer to such "
"features, and each of their definitions indicates how the whole program "
"needs to be constrained in order to remove the safety problem indicated by "
"the keyword. Only when all the reasons that make a function unsafe are "
"observed and addressed, by applying the documented constraints, does the "
"function become safe to call in a context."
msgstr ""
"Pour certaines fonctionnalités qui rendent non sûre l'appel de certaines "
"fonctions dans certains contextes, il existe des moyens connus pour éviter "
"un problème autres que de s'abstenir complètement d'appeler la fonction. Les "
"mots-clés qui suivent font référence à ces fonctionnalités et chacune des "
"définitions indique comment le programme dans son ensemble doit être "
"contraint de manière à supprimer le problème de sûreté indiqué par le mot-"
"clé. C'est seulement lorsque toutes les raisons qui rendent une fonction non "
"sûre ont été observées et traitées, en appliquant les contraintes "
"documentées, que l'appel d'une fonction devient sûr dans un contexte."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I"
msgstr "I"
#. 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 as an MT-Unsafe feature perform MT-Unsafe "
"initialization when they are first called."
msgstr ""
"Les fonctions marquées I en tant que fonctionnalité I "
"réalisent une initialisation I quand elles sont appelées en "
"premier."
#
#
#
#
#
#. 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 ""
"L'appel d'une fonction de ce type au moins une fois en mode monothread "
"supprime cette raison spécifique qui fait considérer la fonction comme I. S'il ne reste pas d'autre raison, la fonction peut alors être "
"appelée de façon sûre après le démarrage d'autres threads."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I"
msgstr "I"
#
#
#
#
#
#
#
#. #-#-#-#-# 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 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 ""
"Les fonctions marquées I en tant que problème d'état I "
"opèrent sur des objets d'une façon qui peut provoquer des situations de "
"concurrences de données ou des formes similaires d'interférences "
"destructives provoquées par une exécution concurrente. Dans certains cas, "
"les objets sont passés aux fonctions par les utilisateurs ; dans d'autres, "
"ils sont utilisés par les fonctions pour renvoyer des valeurs aux "
"utilisateurs ; dans d'autres encore, ils ne sont même pas exposés aux "
"utilisateurs."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I"
msgstr "I"
#. 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 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, 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 ""
"Les fonctions marquées I en tant que problème d'état MT-Safe "
"modifient de façon non-atomique les objets internes qui sont plutôt à "
"considérer comme constants, parce qu'une partie importante de la "
"bibliothèque GNU C y accède sans synchronisation. À la différence de I "
"qui fait qu'à la fois lecteurs et écrivains d'objets internes sont "
"considérés comme I, cette marque ne s'applique qu'aux écrivains. "
"Leur appel demeure I, mais le caractère constant alors "
"obligatoire des objets qu'ils modifient permet de considérer les lecteurs "
"comme I (aussi longtemps qu'il n'y a pas d'autre raison pour qu'ils "
"soient non sûrs), dans la mesure où l'absence de synchronisation n'est pas "
"un problème quand les objets sont effectivement constants."
#
#. 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 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 calls to functions marked "
"with I followed by the identifier with a write lock, and I calls "
"to functions marked with the identifier by itself with a read lock."
msgstr ""
"L'identifiant qui suit la marque I apparaîtra lui-même conne une note "
"de sûreté dans les lecteurs. Les programmes qui souhaitent contourner ce "
"problème de sûreté, afin d'appeler les écrivains, peuvent utiliser un verrou "
"en lecture et écriture non récursif associé à l'identifiant et garder la "
"I des appels à des fonctions marquées I suivies de "
"l'identifiant avec un verrou en écriture et la I des appels à des "
"fonctions marquées par l'identifiant lui-même avec un verrou en lecture."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I"
msgstr "I"
#. (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 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 ""
"Les fonctions marquées I en tant que problème d'état MT-Safe peuvent "
"installer de façon temporaire un gestionnaire de signal à des fins internes "
"qui peut interférer avec d'autres usages du signal, identifié après deux-"
"points."
#
#
#
#. 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 ""
"Le problème de sûreté peut être contourné en s'assurant qu'aucun autre usage "
"du signal n'interviendra pendant la durée de l'appel. Il est recommandé de "
"maintenir un mutex non récursif pendant l'appel de toutes les fonctions qui "
"utilisent le même signal temporaire, de bloquer ce signal avant l'appel et "
"de réinitialiser son gestionnaire après."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I"
msgstr "I"
#. 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 as an MT-Safety issue may change the terminal "
"settings in the recommended way, namely: call B(3), modify some "
"flags, and then call B(3), this creates a window in which changes "
"made by other threads are lost. Thus, functions marked with I are MT-"
"Unsafe."
msgstr ""
"Les fonctions marquées I en tant que problème d'état MT-Safe peuvent "
"modifier la configuration du terminal de la façon recommandée, c'est-à-"
"dire : appel de B(3), modification de certains attributs puis "
"appel de B(3), cela crée une fenêtre dans laquelle les "
"modifications effectuées par d'autres threads sont perdues. Donc, les "
"fonctions marquées I sont I."
#
#
#
#. 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, where "
"I 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 ""
"Il est donc recommandé d'éviter, pour les applications utilisant le "
"terminal, des interactions simultanées et réentrantes avec lui en "
"nel'utilisant pas dans les gestionnaires de signal ou les signaux bloquants "
"qui pourraient l'utiliser également, et de maintenir un verrou pendant "
"l'utilisation de ces fonctions et l'interaction avec le terminal. Ce verrou "
"devrait également être utilisé pour l'exclusion mutuelle avec les fonctions "
"marquées I où I est un descripteur de fichier pour le "
"terminal de contrôle. L'appelant peut utiliser un mutex unique pour "
"simplifier ou utiliser un mutex par terminal même s'ils sont référencés par "
"des descripteurs de fichier différents."
#. 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 "Autres remarques sur la sûreté"
#. 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 ""
"Des mots clefs supplémentaires peuvent être ajoutés aux fonctions, indiquant "
"des fonctionnalités qui ne rendent pas la fonction non sûre à appeler, mais "
"il peut être nécessaire d'en tenir compte dans certaines classes de "
"programmes."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I"
msgstr "I"
#. 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 as an MT-Safety issue read from the "
"locale object without any form of synchronization. Functions annotated with "
"I 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 ""
"Les fonctions marquées I en tant que problème d'état MT-Safe lisent "
"à partir de l'objet locale sans aucune forme de synchronisation. Ces "
"fonctions appelées en même temps que des modifications de I peuvent "
"se comporter d'une manière qui ne correspond à aucune des I actives "
"pendant leur exécution mais à un mélange imprévisible de celles-ci."
#. 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 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 ""
"Nous ne marquons pas ces fonctions comme I néanmoins, car les "
"fonctions qui modifient l'objet I sont marquées I et "
"considérées comme non sûres. Étant non sûres, ces dernières ne doivent pas "
"être appelées quand plusieurs threads sont en exécution ou lorsque les "
"signaux asynchrones sont activés, et ainsi la I peut être considérée "
"comme effectivement constante dans ces contextes, ce qui rend les premières "
"fonctions sûres."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I"
msgstr "I"
#. 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 as an MT-Safety issue access the environment "
"with B(3) or similar, without any guards to ensure safety in the "
"presence of concurrent modifications."
msgstr ""
"Les fonctions marquées I en tant que problème d'état MT-Safe accèdent à "
"l'environnement avec B(3) ou une commande similaire sans aucune "
"protection pour garantir la sûreté en présence de modifications simultanées."
#. 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 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 ""
"Nous ne marquons pas ces fonctions comme I néanmoins, car les "
"fonctions qui modifient l'environnement sont toutes marquées I et "
"considérées comme non sûres. Étant non sûres, ces dernières ne doivent pas "
"être appelées quand plusieurs threads sont en exécution ou lorsque les "
"signaux asynchrones sont activés, et ainsi l'environnement peut être "
"considéré comme effectivement constant dans ces contextes, ce qui rend les "
"premières fonctions sûres."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I"
msgstr "I"
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"The function marked with I as an MT-Safety issue reads from the "
"system-wide data structures that hold the \"host ID\" of the machine. These "
"data structures cannot generally be modified atomically. Since it is "
"expected that the \"host ID\" will not normally change, the function that "
"reads from it (B(3)) is regarded as safe, whereas the function "
"that modifies it (B(3)) is marked with I, "
"indicating it may require special care if it is to be called. In this "
"specific case, the special care amounts to system-wide (not merely intra-"
"process) coordination."
msgstr ""
"Les fonctions marquées I en tant que problème d'état MT-Safe lisent "
"à partir des structures de données communes à tout le système qui "
"contiennent « l'ID d'hôte » de la machine. Ces structures de données ne "
"peuvent pas en général être modifiées automatiquement. Dans la mesure où il "
"est attendu que normalement « l'ID d'hôte » ne change pas, la fonction qui "
"lit à partir d'elle (B(3)) est considérée comme sûre, tandis que "
"la fonction qui la modifie (B(3)) est marquée I, "
"indiquant qu'elle requiert une attention particulière si elle doit être "
"appelée. Dans ce cas particulier, cette attention particulière équivaut à "
"une coordination à l'échelle de l'ensemble du système (pas seulement à "
"l'intérieur du processus)."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I"
msgstr "I"
#. 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 as an MT-Safety issue access the GNU C "
"Library I<_sigintr> internal data structure without any guards to ensure "
"safety in the presence of concurrent modifications."
msgstr ""
"Les fonctions marquées I en tant que problème d'état MT-Safe "
"accèdent à la structure de données interne I<_sigintr> de la bibliothèque "
"GNU C sans aucune protection pour garantir la sûreté en présence de "
"modifications simultanées."
#
#
#
#
#
#. or AS-Unsafe,
#. .TP
#. .I fd
#. Functions annotated with
#. .I fd
#. as an AC-Safety issue may leak file
#. descriptors if asynchronous thread cancelation interrupts their
#. execution.
#. Functions that allocate or deallocate file descriptors will generally be
#. marked as such.
#. Even if they attempted to protect the file descriptor
#. allocation and deallocation with cleanup regions,
#. allocating a new descriptor and storing its number where the cleanup region
#. could release it cannot be performed as a single atomic operation.
#. Similarly,
#. releasing the descriptor and taking it out of the data structure
#. normally responsible for releasing it cannot be performed atomically.
#. There will always be a window in which the descriptor cannot be released
#. because it was not stored in the cleanup handler argument yet,
#. or it was already taken out before releasing it.
#. .\" It cannot be taken out after release:
#. an open descriptor could mean either that the descriptor still
#. has to be closed,
#. or that it already did so but the descriptor was
#. reallocated by another thread or signal handler.
#. Such leaks could be internally avoided, with some performance penalty,
#. by temporarily disabling asynchronous thread cancelation.
#. However,
#. since callers of allocation or deallocation functions would have to do
#. this themselves, to avoid the same sort of leak in their own layer,
#. it makes more sense for the library to assume they are taking care of it
#. than to impose a performance penalty that is redundant when the problem
#. is solved in upper layers, and insufficient when it is not.
#. This remark by itself does not cause a function to be regarded as
#. AC-Unsafe.
#. However, cumulative effects of such leaks may pose a
#. problem for some programs.
#. If this is the case,
#. suspending asynchronous cancelation for the duration of calls
#. to such functions is recommended.
#. .TP
#. .I mem
#. Functions annotated with
#. .I mem
#. as an AC-Safety issue may leak
#. memory if asynchronous thread cancelation interrupts their execution.
#. The problem is similar to that of file descriptors: there is no atomic
#. interface to allocate memory and store its address in the argument to a
#. cleanup handler,
#. or to release it and remove its address from that argument,
#. without at least temporarily disabling asynchronous cancelation,
#. which these functions do not do.
#. This remark does not by itself cause a function to be regarded as
#. generally AC-Unsafe.
#. However, cumulative effects of such leaks may be
#. severe enough for some programs that disabling asynchronous cancelation
#. for the duration of calls to such functions may be required.
#. 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 this data structure are all marked with I 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 data "
"structure can be considered effectively constant in these contexts, which "
"makes the former safe."
msgstr ""
"Nous ne marquons pas ces fonctions comme I néanmoins, car les "
"fonctions qui modifient cette structure de données sont toutes marquées "
"I et considérées comme non sûres. Étant non sûres, ces "
"dernières ne doivent pas être appelées quand plusieurs threads sont en "
"exécution ou lorsque les signaux asynchrones sont activés, et ainsi "
"l'environnement peut être considéré comme effectivement constant dans ces "
"contextes, ce qui rend les premières fonctions sûres."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I"
msgstr "I"
#. 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 as an MT-Safety issue may temporarily change "
"the current working directory during their execution, which may cause "
"relative pathnames to be resolved in unexpected ways in other threads or "
"within asynchronous signal or cancelation handlers."
msgstr ""
"Les fonctions marquées I en tant que problème d'état MT-Safe peuvent "
"changer temporairement le répertoire actif actuel durant leur exécution ce "
"qui fait que les noms de chemin relatifs peuvent être résolus de façon "
"inattendue dans les autres threads ou dans les gestionnaires de signal ou "
"d'annulation asynchrones."
#
#. or AS-Unsafe,
#. .TP
#. .I !posix
#. This remark, as an MT-Safety, AS-Safety or AC-Safety
#. note to a function,
#. indicates the safety status of the function is known to differ
#. from the specified status in the POSIX standard.
#. For example, POSIX does not require a function to be Safe,
#. but our implementation is, or vice-versa.
#. For the time being, the absence of this remark does not imply the safety
#. properties we documented are identical to those mandated by POSIX for
#. the corresponding functions.
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"This is not enough of a reason to mark so-marked functions as MT-Unsafe, but "
"when this behavior is optional (e.g., B(3) with B), "
"avoiding the option may be a good alternative to using full pathnames or "
"file descriptor-relative (e.g., B(2)) system calls."
msgstr ""
"Ce n'est pas une raison suffisante pour marquer comme I les "
"fonctions ainsi marquées, mais quand ce comportement est optionnel (par "
"exemple, B(3) avec B), éviter l'option peut être une bonne "
"alternative à l'utilisation des noms de chemin complets ou d'appels système "
"relatifs au descripteur de fichier (par exemple, B(2))."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I<:identifier>"
msgstr "I<:identifiant>"
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"Annotations may sometimes be followed by identifiers, intended to group "
"several functions that, for example, access the data structures in an unsafe "
"way, as in I and I, or to provide more specific information, "
"such as naming a signal in a function marked with I. It is envisioned "
"that it may be applied to I and I as well in the future."
msgstr ""
"Les annotations peuvent parfois être suivies par des identifiants destinés à "
"regrouper plusieurs fonctions qui, par exemple accèdent aux structures de "
"données de façon non sûre, comme dans I et I, ou pour fournir "
"des informations plus spécifiques, comme le nom d'un signal dans une "
"fonction marquée I. Il est envisagé que cela pourrait aussi être "
"appliqué à l'avenir à I et I."
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"In most cases, the identifier will name a set of functions, but it may name "
"global objects or function arguments, or identifiable properties or logical "
"components associated with them, with a notation such as, for example, I<:"
"buf(arg)> to denote a buffer associated with the argument I, or I<:"
"tcattr(fd)> to denote the terminal attributes of a file descriptor I."
msgstr ""
"Dans la plupart des cas, l'identifiant désignera un ensemble de fonctions, "
"mais il peut désigner des objets globaux ou des paramètres de fonction, des "
"propriétés identifiables ou des composants logiques qui leur sont associés, "
"avec une notation du type, par exemple, I<:buf(param)> pour désigner un "
"tampon associé au paramètre I, ou I<:tcattr(fd)> pour désigner les "
"attributs de terminal d'un descripteur de fichier I."
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"The most common use for identifiers is to provide logical groups of "
"functions and arguments that need to be protected by the same "
"synchronization primitive in order to ensure safe operation in a given "
"context."
msgstr ""
"L'utilisation la plus courante des identifiants est de fournir des groupes "
"logiques de fonctions et de paramètres qui nécessitent d'être protégés par "
"la même primitive de synchronisation afin d'assurer une opération sûre dans "
"un contexte donné."
#. type: TP
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "I"
msgstr "I"
#. Such conditions as
#. .I /hurd
#. or
#. .I /!linux!bsd
#. indicate the preceding marker only
#. applies when the underlying kernel is the HURD,
#. or when it is neither Linux nor a BSD kernel, respectively.
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"Some safety annotations may be conditional, in that they only apply if a "
"boolean expression involving arguments, global variables or even the "
"underlying kernel evaluates to true. For example, I and I indicate the preceding marker only applies when argument I "
"is NULL, or global variable I is nonzero."
msgstr ""
"Certaines annotations de sûreté peuvent être conditionnelles, dans le sens "
"qu'elles ne s'appliquent que si une expression booléenne comprenant des "
"paramètres, des variables globales ou même le noyau sous-jacent est évaluée "
"vraie. Par exemple, I et I indiquent que le marqueur "
"qui précède ne s'applique que si l'argument I est NULL ou la variable "
"globale I est différente de zéro.'"
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid ""
"When all marks that render a function unsafe are adorned with such "
"conditions, and none of the named conditions hold, then the function can be "
"regarded as safe."
msgstr ""
"Quand toutes les marques qui rendent non sûre une fonction sont agrémentées "
"de conditions de ce type, et qu'aucune des conditions nommées ne tient, "
"alors, la fonction peut être considérée comme sûre."
#. type: SH
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
#, no-wrap
msgid "SEE ALSO"
msgstr "VOIR AUSSI"
#. type: Plain text
#: archlinux debian-bookworm debian-unstable fedora-40 fedora-rawhide
#: mageia-cauldron opensuse-leap-15-6 opensuse-tumbleweed
msgid "B(7), B(7)"
msgstr "B(7), B(7)"
#. type: TH
#: debian-bookworm
#, no-wrap
msgid "2022-10-30"
msgstr "30 octobre 2022"
#. type: TH
#: debian-bookworm
#, no-wrap
msgid "Linux man-pages 6.03"
msgstr "Pages du manuel de Linux 6.03"
#. type: TH
#: fedora-40 fedora-rawhide mageia-cauldron
#, no-wrap
msgid "2023-11-01"
msgstr "1 novembre 2023"
#. type: TH
#: fedora-40 mageia-cauldron
#, no-wrap
msgid "Linux man-pages 6.06"
msgstr "Pages du manuel de Linux 6.06"
#. type: TH
#: fedora-rawhide
#, no-wrap
msgid "Linux man-pages 6.7"
msgstr "Pages du manuel de Linux 6.7"
#. type: TH
#: opensuse-leap-15-6
#, no-wrap
msgid "2023-03-18"
msgstr "18 mars 2023"
#. type: TH
#: opensuse-leap-15-6
#, no-wrap
msgid "Linux man-pages 6.04"
msgstr "Pages du manuel de Linux 6.04"
#. type: TH
#: opensuse-tumbleweed
#, no-wrap
msgid "Linux man-pages (unreleased)"
msgstr "Pages du manuel de Linux (non publiées)"