.\" -*- coding: UTF-8 -*-
.\" Copyright 2014, Red Hat, Inc.
.\" Copyright, the authors of the Linux man-pages project
.\"
.\" SPDX-License-Identifier: GPL-2.0-or-later
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH سمات 7 "8 فبراير 2026" "صفحات دليل لينكس 6.18" 
.SH الاسم
attributes \- مفاهيم السلامة في POSIX
.SH الوصف
.\"
.\"
\fIملاحظة\fP: نص صفحة الدليل هذه مبني على المادة المأخوذة من قسم "مفاهيم
السلامة في POSIX" من دليل مكتبة GNU C. يمكن العثور على تفاصيل إضافية حول
الموضوعات الموصوفة هنا في ذلك الدليل.
.P
تتضمن صفحات دليل الدوال المختلفة قسماً بعنوان ATTRIBUTES يصف سلامة استدعاء
الدالة في سياقات مختلفة. يقوم هذا القسم بتعليق الدوال بعلامات السلامة
التالية:
.TP 
\fIMT\-Safe\fP
الدوال \fIالآمنة للخيوط\fP أو Thread\-Safe آمنة للاستدعاء في وجود خيوط أخرى. MT
في MT\-Safe ترمز إلى Multi Thread (خيوط متعددة).
.IP
كون الدالة آمنة للخيوط لا يعني أنها ذرية، ولا أنها تستخدم أي آليات مزامنة
للذاكرة التي يعرضها POSIX للمستخدمين. حتى أنه من الممكن أن استدعاء دوال آمنة
للخيوط بالتسلسل لا ينتج عنه تركيبة آمنة للخيوط. على سبيل المثال، جعل خيط
يستدعي دالتين آمنتين للخيوط واحدة تلو الأخرى لا يضمن سلوكاً مكافئاً للتنفيذ
الذري لتركيبة كلتا الدالتين، لأن الاستدعاءات المتزامنة في خيوط أخرى قد
تتداخل بطريقة مدمرة.
.IP
.\" .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.
تحسينات البرنامج الكامل التي قد تقوم بتضمين الدوال عبر واجهات المكتبة قد
تعرض إعادة ترتيب غير آمنة، ولذا لا يُوصى بإجراء التضمين عبر واجهة مكتبة GNU
C. حالة الأمان للخيوط الموثقة غير مضمونة تحت تحسين البرنامج الكامل. ومع ذلك،
فإن الدوال المعرفة في ملفات الرأس المرئية للمستخدم مصممة لتكون آمنة للتضمين.
.TP 
.\" ,\~ AS-Unsafe ,\~ AC-Unsafe
\fIMT\-Unsafe\fP
.\" ,\~ 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.
الدوال \fIغير الآمنة للخيوط\fP ليست آمنة للاستدعاء في برامج متعددة الخيوط.
.P
.\"
.\"
.\" .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.
.\"
.\"
الكلمات المفتاحية الأخرى التي تظهر في ملاحظات السلامة تُعرف في الأقسام
اللاحقة.
.SS "الميزات الآمنة بشروط"
بالنسبة لبعض الميزات التي تجعل الدوال غير آمنة للاستدعاء في سياقات معينة،
هناك طرق معروفة لتجنب مشكلة السلامة بخلاف الامتناع عن استدعاء الدالة
بالكامل. تشير الكلمات المفتاحية التالية إلى هذه الميزات، ويشير كل تعريف منها
إلى كيفية تقييد البرنامج الكامل لإزالة مشكلة السلامة المشار إليها بالكلمة
المفتاحية. فقط عندما يتم ملاحظة ومعالجة جميع الأسباب التي تجعل الدالة غير
آمنة، من خلال تطبيق القيود الموثقة، تصبح الدالة آمنة للاستدعاء في سياق ما.
.TP 
\fIinit\fP
الدوال الموسومة بـ \fIinit\fP كميزة غير آمنة للخيوط تقوم بتهيئة غير آمنة للخيوط
عند استدعائها لأول مرة.
.IP
.\"
.\" 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.
استدعاء هذه الدالة مرة واحدة على الأقل في وضع الخيط الواحد يزيل هذا السبب
المحدد لاعتبار الدالة غير آمنة للخيوط. إذا لم يبق سبب آخر لذلك، يمكن عندها
استدعاء الدالة بأمان بعد بدء الخيوط الأخرى.
.TP 
\fIrace\fP
.\"
.\" 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.
الدوال المشروحة بـ \fIrace\fP كمشكلة أمان للخيوط تعمل على كائنات بطرق قد تسبب
سباقات بيانات أو أشكالاً مماثلة من التداخل المدمر الناتج عن التنفيذ
المتزامن. في بعض الحالات، يتم تمرير الكائنات إلى الدوال بواسطة المستخدمين؛
وفي حالات أخرى، تُستخدم بواسطة الدوال لإرجاع قيم للمستخدمين؛ وفي حالات أخرى،
لا يتم حتى كشفها للمستخدمين.
.TP 
\fIconst\fP
.\" and AS-Unsafe,
.\" equally
.\" and AS-Unsafe
.\" and AS-Safe
الدوال الموسومة بـ \fIconst\fP كمشكلة أمان للخيوط تقوم بتعديل كائنات داخلية
بشكل غير ذري يُفضل اعتبارها ثابتة، لأن جزءاً كبيراً من مكتبة GNU C يصل إليها
دون مزامنة. على عكس \fIrace\fP، الذي يتسبب في اعتبار كل من قارئي وكاتبي
الكائنات الداخلية غير آمنين للخيوط، يتم تطبيق هذه العلامة على الكُتّاب
فقط. يظل الكُتّاب غير آمنين للاستدعاء، لكن الثبات الإجباري للكائنات التي
يعدلونها يمكن القُرّاء من اعتبارهم آمنين للخيوط (طالما لم تبق أسباب أخرى
لعدم أمانهم)، لأن غياب المزامنة ليس مشكلة عندما تكون الكائنات ثابتة فعلياً.
.IP
.\" 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.
المُعرّف الذي يتبع علامة \fIconst\fP سيظهر بمفرده كملاحظة سلامة في
القُرّاء. البرامج التي ترغب في تجاوز مشكلة السلامة هذه، لاستدعاء الكُتّاب،
قد تستخدم قفل قراءة\-كتابة غير استرجاعي مرتبط بالمُعرّف، وتحمي \fIجميع\fP
الاستدعاءات للدوال الموسومة بـ \fIconst\fP متبوعة بالمُعرّف بقفل كتابة،
و\fIجميع\fP الاستدعاءات للدوال الموسومة بالمُعرّف بمفرده بقفل قراءة.
.TP 
\fIsig\fP
.\" (that implies an identical AS-Safety issue, omitted for brevity)
الدوال الموسومة بـ \fIsig\fP كمشكلة أمان للخيوط قد تقوم بتثبيت معالج إشارة
مؤقتاً لأغراض داخلية، مما قد يتداخل مع الاستخدامات الأخرى للإشارة، المُعرّفة
بعد نقطتين.
.IP
.\"
.\" 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.
يمكن تجاوز مشكلة السلامة هذه بضمان عدم حدوث استخدامات أخرى للإشارة طوال مدة
الاستدعاء. يُوصى بحمل كائن مزامنة (mutex) غير استرجاعي أثناء استدعاء جميع
الدوال التي تستخدم نفس الإشارة المؤقتة؛ وحظر تلك الإشارة قبل الاستدعاء
وإعادة تعيين معالجها بعده.
.TP 
\fIterm\fP
.\" 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.
الدوال الموسومة بـ \fIterm\fP كمشكلة أمان للخيوط قد تغير إعدادات الطرفية
بالطريقة الموصى بها، وهي: استدعاء \fBtcgetattr\fP(3)، تعديل بعض الأعلام، ثم
استدعاء \fBtcsetattr\fP(3)، مما يخلق نافذة يتم فيها فقدان التغييرات التي أجرتها
خيوط أخرى. وبالتالي، الدوال الموسومة بـ \fIterm\fP غير آمنة للخيوط.
.IP
.\"
.\" 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.
.\"
.\"
لذا يُنصح التطبيقات التي تستخدم الطرفية بتجنب التفاعلات المتزامنة وإعادة
الدخول معها، بعدم استخدامها في معالجات الإشارات أو حظر الإشارات التي قد
تستخدمها، وحمل قفل أثناء استدعاء هذه الدوال والتفاعل مع الطرفية. يجب أيضًا
استخدام هذا القفل للاستبعاد المتبادل مع الدوال الموسومة بـ
\fIrace:tcattr(fd)\fP، حيث \fIfd\fP هو واصف ملف للطرفية المسيطرة. قد يستخدم
المستدعي كائن مزامنة واحداً للبساطة، أو استخدام كائن مزامنة واحد لكل طرفية،
حتى لو تمت الإشارة إليها بواسطة واصفات ملفات مختلفة.
.SS "ملاحظات أمان أخرى"
قد تُرفق كلمات مفتاحية إضافية بالدوال، للإشارة إلى ميزات لا تجعل استدعاء
الدالة غير آمن، ولكن قد يلزم أخذها بعين الاعتبار في فئات معينة من البرامج:
.TP 
\fIlocale\fP
الدوال المُعلّمة بـ \fIlocale\fP كمشكلة أمان خيوط التنفيذ تقرأ من كائن
الإعدادات المحلية دون أي شكل من أشكال التزامن. الدوال المُعلّمة بـ \fIlocale\fP
التي تُستدعى بالتزامن مع تغييرات الإعدادات المحلية قد تتصرف بطرق لا تتوافق
مع أي من الإعدادات المحلية النشطة أثناء تنفيذها، بل بمزيج غير متوقع منها.
.IP
.\" 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.
مع ذلك، لا نُعلّم هذه الدوال كغير آمنة للخيوط، لأن الدوال التي تُعدّل كائن
الإعدادات المحلية مُعلّمة بـ \fIconst:locale\fP وتُعتبر غير آمنة. لكونها غير
آمنة، لا ينبغي استدعاء الأخيرة عند تشغيل خيوط متعددة أو تمكين الإشارات غير
المتزامنة، وبالتالي يمكن اعتبار الإعدادات المحلية ثابتة فعليًا في هذه
السياقات، مما يجعل الأولى آمنة.
.TP 
\fIenv\fP
الدوال المُعلّمة بـ \fIenv\fP كمشكلة أمان خيوط التنفيذ تصل إلى البيئة باستخدام
\fBgetenv\fP(3) أو ما شابه، دون أي حراس لضمان الأمان في وجود تعديلات متزامنة.
.IP
.\" or AS-Unsafe,
مع ذلك، لا نُعلّم هذه الدوال كغير آمنة للخيوط، لأن الدوال التي تُعدّل البيئة
كلها مُعلّمة بـ \fIconst:env\fP وتُعتبر غير آمنة. لكونها غير آمنة، لا ينبغي
استدعاء الأخيرة عند تشغيل خيوط متعددة أو تمكين الإشارات غير المتزامنة،
وبالتالي يمكن اعتبار البيئة ثابتة فعليًا في هذه السياقات، مما يجعل الأولى
آمنة.
.TP 
\fIhostid\fP
الدوال المُعلّمة بـ \fIhostid\fP كمشكلة أمان خيوط التنفيذ تقرأ من هياكل
البيانات على مستوى النظام التي تحتوي على "معرف المضيف" للجهاز. لا يمكن تعديل
هياكل البيانات هذه بشكل ذري عمومًا. نظرًا لأنه من المتوقع ألا يتغير "معرف
المضيف" عادةً، تُعتبر الدالة التي تقرأ منه (\fBgethostid\fP(3)) آمنة، بينما
الدالة التي تُعدّله (\fBsethostid\fP(3)) مُعلّمة بـ \fIconst:hostid\fP، مما يشير
إلى أنها قد تتطلب عناية خاصة إذا كان سيتم استدعاؤها. في هذه الحالة المحددة،
تعادل العناية الخاصة التنسيق على مستوى النظام (وليس فقط داخل العملية).
.TP 
\fIsigintr\fP
الدوال المُعلّمة بـ \fIsigintr\fP كمشكلة أمان خيوط التنفيذ تصل إلى هيكل
البيانات الداخلي \fI_sigintr\fP لمكتبة C لجنو دون أي حراس لضمان الأمان في وجود
تعديلات متزامنة.
.IP
.\" 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.
مع ذلك، لا نُعلّم هذه الدوال كغير آمنة للخيوط، لأن الدوال التي تُعدّل هيكل
البيانات هذا كلها مُعلّمة بـ \fIconst:sigintr\fP وتُعتبر غير آمنة. لكونها غير
آمنة، لا ينبغي استدعاء الأخيرة عند تشغيل خيوط متعددة أو تمكين الإشارات غير
المتزامنة، وبالتالي يمكن اعتبار هيكل البيانات ثابتًا فعليًا في هذه السياقات،
مما يجعل الأولى آمنة.
.TP 
\fIcwd\fP
الدوال المُعلّمة بـ \fIcwd\fP كمشكلة أمان خيوط التنفيذ قد تُغيّر دليل العمل
الحالي مؤقتًا أثناء تنفيذها، مما قد يتسبب في حل أسماء المسارات النسبية بطرق
غير متوقعة في خيوط أخرى أو داخل معالجات الإشارات غير المتزامنة أو الإلغاء.
.IP
.\" 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.
هذا ليس سببًا كافيًا لتعليم الدوال المُعلّمة بهذا الشكل كغير آمنة للخيوط،
ولكن عندما يكون هذا السلوك اختياريًا (مثل \fBnftw\fP(3) مع \fBFTW_CHDIR\fP)، قد
يكون تجنب الخيار بديلاً جيدًا لاستخدام أسماء المسارات الكاملة أو استدعاءات
النظام المتعلقة بوصف الملف (مثل \fBopenat\fP(2)).
.TP 
\fI:identifier\fP
قد تُتبع التعليقات أحيانًا بمُعرّفات، تهدف إلى تجميع عدة دوال تصل، على سبيل
المثال، إلى هياكل البيانات بطريقة غير آمنة، كما في \fIrace\fP و \fIconst\fP، أو
لتوفير معلومات أكثر تحديدًا، مثل تسمية إشارة في دالة مُعلّمة بـ \fIsig\fP. من
المتصور أنه قد يُطبق على \fIlock\fP و \fIcorrupt\fP أيضًا في المستقبل.
.IP
في معظم الحالات، سيُسمي المُعرّف مجموعة من الدوال، ولكنه قد يُسمي كائنات
عامة أو وسائط دالة، أو خصائص قابلة للتحديد أو مكونات منطقية مرتبطة بها،
بتدوين مثل، على سبيل المثال، \fI:buf(arg)\fP للدلالة على مخزن مؤقت مرتبط
بالوسيطة \fIarg\fP، أو \fI:tcattr(fd)\fP للدلالة على سمات الطرفية لوصف ملف \fIfd\fP.
.IP
الاستخدام الأكثر شيوعًا للمُعرّفات هو توفير مجموعات منطقية من الدوال
والوسائط التي تحتاج إلى الحماية بواسطة نفس بدائية التزامن لضمان التشغيل
الآمن في سياق معين.
.TP 
\fI/condition\fP
.\" 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.
قد تكون بعض تعليقات الأمان شرطية، حيث تنطبق فقط إذا كان تعبير منطقي يتضمن
وسائط أو متغيرات عامة أو حتى النواة الأساسية يُقيّم إلى صحيح. على سبيل
المثال، يشير \fI/!ps\fP و \fI/one_per_line\fP إلى أن العلامة السابقة تنطبق فقط
عندما تكون الوسيطة \fIps\fP فارغة (NULL)، أو المتغير العام \fIone_per_line\fP غير
صفري.
.IP
عندما تكون جميع العلامات التي تجعل الدالة غير آمنة مُزيّنة بمثل هذه الشروط،
ولا ينطبق أي من الشروط المُسمّاة، يمكن اعتبار الدالة آمنة.
.SH "انظر أيضًا"
\fBpthreads\fP(7), \fBsignal\-safety\fP(7)
.PP
.SH ترجمة
تُرجمت هذه الصفحة من الدليل بواسطة
زايد السعيدي <zayed.alsaidi@gmail.com>
.
.PP
هذه الترجمة هي وثيقة مجانية؛ راجع
.UR https://www.gnu.org/licenses/gpl-3.0.html 
رخصة جنو العامة الإصدار 3
.UE
أو ما بعده للاطلاع على شروط حقوق النشر.
لا توجد أي ضمانات.
.PP
إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه،
يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين:
.MT kde-l10n-ar@kde.org
.ME .