Lines Matching refs:objects

509 objects in ways that may cause data races or similar forms of
511 the objects are passed to the functions by users; in others, they are
515 We consider access to objects passed as (indirect) arguments to
516 functions to be data race free.  The assurance of data race free objects
520 objects.  As a general rule, if a function is documented as reading from
526 races in many functions that manipulate objects of this specific opaque
531 responsibility, we will annotate functions that take objects of certain
532 types as arguments.  We draw the line for objects passed by users as
533 follows: objects whose types are exposed to users, and that users are
538 by the library's lack of internal guards when accessing objects that can
541 As for objects that are opaque or opaque-like, in that they are to be
546 argument name, functions that take such objects but that do not take
554 access user-supplied objects in unsafe ways should users fail to ensure
556 expected to safeguard against data races any user-supplied objects that
561 This user responsibility does not apply, however, to objects controlled
562 by the library itself, such as internal objects and static buffers used
567 user-exposed objects, the mark may be followed by a colon and an
570 with unguarded concurrent access to such internal objects by creating a
594 modify internal objects that are better regarded as constant, because a
597 writers of internal objects to be regarded as MT-Unsafe and AS-Unsafe,
599 AS-Unsafe to call, but the then-mandatory constness of objects they
602 synchronization is not a problem when the objects are effectively
870 name global objects or function arguments, or identifiable properties or
1383 @w{@code{FILE *}} objects).  These are the normal C library functions