tmp/tmp13som6wg/{from.md → to.md}
RENAMED
|
@@ -4,24 +4,24 @@ Conformance is specified in terms of behavior. Ideal behavior is not
|
|
| 4 |
always implementable, so the conformance subclauses take that into
|
| 5 |
account.
|
| 6 |
|
| 7 |
#### POSIX conformance <a id="fs.conform.9945">[[fs.conform.9945]]</a>
|
| 8 |
|
| 9 |
-
Some behavior is specified by reference to POSIX
|
| 10 |
such behavior is actually implemented is unspecified.
|
| 11 |
|
| 12 |
[*Note 1*: This constitutes an “as if” rule allowing implementations to
|
| 13 |
call native operating system or other APIs. — *end note*]
|
| 14 |
|
| 15 |
-
Implementations
|
| 16 |
-
|
| 17 |
-
|
| 18 |
-
POSIX behavior
|
| 19 |
-
|
| 20 |
-
systems
|
| 21 |
-
|
| 22 |
-
|
| 23 |
|
| 24 |
[*Note 2*: This allows users to rely on an exception being thrown or an
|
| 25 |
error code being set when an implementation cannot provide any
|
| 26 |
reasonable behavior. — *end note*]
|
| 27 |
|
|
@@ -34,26 +34,30 @@ other features of more capable file systems, so implementations are not
|
|
| 34 |
required to support those features on the FAT file system but instead
|
| 35 |
are required to report an error as described above. — *end example*]
|
| 36 |
|
| 37 |
#### Operating system dependent behavior conformance <a id="fs.conform.os">[[fs.conform.os]]</a>
|
| 38 |
|
| 39 |
-
|
| 40 |
-
|
| 41 |
-
|
|
|
|
| 42 |
|
| 43 |
It is permissible for an implementation to be dependent upon an
|
| 44 |
operating system emulator rather than the actual underlying operating
|
| 45 |
system.
|
| 46 |
|
| 47 |
#### File system race behavior <a id="fs.race.behavior">[[fs.race.behavior]]</a>
|
| 48 |
|
| 49 |
-
|
| 50 |
-
|
|
|
|
|
|
|
|
|
|
| 51 |
|
| 52 |
If the possibility of a file system race would make it unreliable for a
|
| 53 |
program to test for a precondition before calling a function described
|
| 54 |
-
herein, *
|
| 55 |
|
| 56 |
[*Note 1*: As a design practice, preconditions are not specified when
|
| 57 |
it is unreasonable for a program to detect them prior to calling the
|
| 58 |
function. — *end note*]
|
| 59 |
|
|
|
|
| 4 |
always implementable, so the conformance subclauses take that into
|
| 5 |
account.
|
| 6 |
|
| 7 |
#### POSIX conformance <a id="fs.conform.9945">[[fs.conform.9945]]</a>
|
| 8 |
|
| 9 |
+
Some behavior is specified by reference to POSIX [[fs.norm.ref]]. How
|
| 10 |
such behavior is actually implemented is unspecified.
|
| 11 |
|
| 12 |
[*Note 1*: This constitutes an “as if” rule allowing implementations to
|
| 13 |
call native operating system or other APIs. — *end note*]
|
| 14 |
|
| 15 |
+
Implementations should provide such behavior as it is defined by POSIX.
|
| 16 |
+
Implementations shall document any behavior that differs from the
|
| 17 |
+
behavior defined by POSIX. Implementations that do not support exact
|
| 18 |
+
POSIX behavior should provide behavior as close to POSIX behavior as is
|
| 19 |
+
reasonable given the limitations of actual operating systems and file
|
| 20 |
+
systems. If an implementation cannot provide any reasonable behavior,
|
| 21 |
+
the implementation shall report an error as specified in
|
| 22 |
+
[[fs.err.report]].
|
| 23 |
|
| 24 |
[*Note 2*: This allows users to rely on an exception being thrown or an
|
| 25 |
error code being set when an implementation cannot provide any
|
| 26 |
reasonable behavior. — *end note*]
|
| 27 |
|
|
|
|
| 34 |
required to support those features on the FAT file system but instead
|
| 35 |
are required to report an error as described above. — *end example*]
|
| 36 |
|
| 37 |
#### Operating system dependent behavior conformance <a id="fs.conform.os">[[fs.conform.os]]</a>
|
| 38 |
|
| 39 |
+
Behavior that is specified as being *operating system dependent* is
|
| 40 |
+
dependent upon the behavior and characteristics of an operating system.
|
| 41 |
+
The operating system an implementation is dependent upon is
|
| 42 |
+
*implementation-defined*.
|
| 43 |
|
| 44 |
It is permissible for an implementation to be dependent upon an
|
| 45 |
operating system emulator rather than the actual underlying operating
|
| 46 |
system.
|
| 47 |
|
| 48 |
#### File system race behavior <a id="fs.race.behavior">[[fs.race.behavior]]</a>
|
| 49 |
|
| 50 |
+
A *file system race* is the condition that occurs when multiple threads,
|
| 51 |
+
processes, or computers interleave access and modification of the same
|
| 52 |
+
object within a file system. Behavior is undefined if calls to functions
|
| 53 |
+
provided by subclause [[fs.race.behavior]] introduce a file system
|
| 54 |
+
race.
|
| 55 |
|
| 56 |
If the possibility of a file system race would make it unreliable for a
|
| 57 |
program to test for a precondition before calling a function described
|
| 58 |
+
herein, *Preconditions:* is not specified for the function.
|
| 59 |
|
| 60 |
[*Note 1*: As a design practice, preconditions are not specified when
|
| 61 |
it is unreasonable for a program to detect them prior to calling the
|
| 62 |
function. — *end note*]
|
| 63 |
|