|
Viewing Issue Simple Details
[ Jump to Notes ]
|
[ Issue History ]
[ Print ]
|
|
ID |
Category |
Severity |
Type |
Date Submitted |
Last Update |
|
0001672 |
[Issue 8 drafts] System Interfaces |
Comment |
Clarification Requested |
2023-04-18 09:11 |
2023-07-03 10:49 |
|
|
Reporter |
geoffclare |
View Status |
public |
|
|
Assigned To |
|
|
Priority |
normal |
Resolution |
Accepted |
|
|
Status |
Applied |
|
Product Version |
Draft 3 |
|
|
Name |
Geoff Clare |
|
Organization |
The Open Group |
|
User Reference |
|
|
Section |
lockf() |
|
Page Number |
1355 |
|
Line Number |
45590 |
|
Final Accepted Text |
|
|
|
Summary |
0001672: Wording improvement to lockf() APPLICATION USAGE |
|
Description |
Bug 0000768 added a paragraph to the fcntl() APPLICATION USAGE that was based on existing text on the lockf() page, but with improved wording. The same wording improvement should be made on the lockf() page.
|
|
Desired Action |
Change:Record-locking should not be used in combination with the fopen(), fread(), fwrite(), and other stdio functions. Instead, the more primitive, non-buffered functions (such as open()) should be used. Unexpected results may occur in processes that do buffering in the user address space. The process may later read/write data which is/was locked. The stdio functions are the most common source of unexpected buffering. to:Record-locking should not be used in combination with buffered standard I/O streams (see [xref to Section 2.5]). Instead, non-buffered I/O should be used. Unexpected results may occur in processes that do buffering in the user address space. The process may later read/write data which is/was locked. Functions that operate on standard I/O streams are the most common source of such buffering.
|
| Tags |
applied_after_i8d3, issue8 |
|
|
Attached Files |
|
|
|
Relationships 
