 Relationships |
|
| Anonymous | Login | 2024-10-09 03:07 UTC |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
| ID | Category | Severity | Type | Date Submitted | Last Update | ||
| 0001296 | [1003.1(2016/18)/Issue7+TC2] System Interfaces | Objection | Error | 2019-10-06 15:54 | 2024-06-11 09:08 | ||
| Reporter | dennisw | View Status | public | ||||
| Assigned To | |||||||
| Priority | normal | Resolution | Accepted | ||||
| Status | Closed | ||||||
| Name | Dennis Wölfing | ||||||
| Organization | |||||||
| User Reference | |||||||
| Section | tmpfile | ||||||
| Page Number | 2162 | ||||||
| Line Number | 69312-69313 | ||||||
| Interp Status | --- | ||||||
| Final Accepted Text | |||||||
| Summary | 0001296: EOVERFLOW does not make sense for tmpfile | ||||||
| Description |
The errors section of tmpfile contains an EOVERFLOW error for when the file size does not fit into an off_t. However this does not make sense because tmpfile creates a new empty file. |
||||||
| Desired Action |
On page 2162 line 69312-69313 section tmpfile, delete:[EOVERFLOW]The file is a regular file and the size of the file cannot be represented correctly |
||||||
| Tags | tc3-2008 | ||||||
| Attached Files | |||||||
|
|
|||||||
|
Relationships |
|
|
Notes |
|
|
(0004618) Don Cragun (manager) 2019-10-14 16:22 edited on: 2019-10-14 16:37 |
The EOVERFLOW error condition shouldn't just be for the size of the newly created file, it should also apply to the size of the directory in which the file being created (which frequently increases in size when a new directory entry is added). Although it would be unusual for a directory to grow to that point, there is no reason to think that it would be impossible. |
|
(0004619) shware_systems (reporter) 2019-10-14 20:30 |
From the tmpfile() Change History: In the ERRORS section, the [EOVERFLOW] condition is added. This change is to support large files. From this I construe its presence as: while the "wb+" flags requirement ensures the length is initially zero, this can be considered a warning, more than error, that any persistence of the file is on media that permits the file to grow past what ofs_t supports for the compiler model used to compile the application. The text is not explicit about whether maximum or current size was intended, so this may be off. Whether this possibility should preclude a file being opened anyways I can see as arguable; it's more on an application to keep the file from growing that large. As Don notes, this may apply to files of type directory too on some implementations, not regular files only; that the act of creating the file grows the directory past that limit - I'd hope a separate error number would indicate this, however, not overload EOVERFLOW. |
|
(0004621) geoffclare (manager) 2019-10-15 09:59 edited on: 2019-12-12 17:18 |
Re: Note: 0004618 It is clear from the way the EOVERFLOW condition is worded that it does not apply to the directory in which the file is being created (emphasis added):The file is a regular file and the size of the file cannot ... I believe the presence of EOVERFLOW on the tmpfile() page is the result of an editorial error when applying the changes in the Large File Summit white paper during work on Issue 5. The relevant section (taken from http://www.opengroup.org/platform/lfs.html [^] ) is: 2.2.1.9 fopen(), freopen(), tmpfile() DESCRIPTION The largest value that can be represented correctly in an object of type off_t will be established as the offset maximum in the open file description. ERRORS The fopen() and freopen() functions will fail if: Notice that the section heading includes tmpfile() but the error condition text is only for fopen() and freopen(). It is easy to see how the editor could have mistakenly applied the error condition change to tmpfile() as well. |
|
(0004623) joerg (reporter) 2019-10-15 10:25 edited on: 2019-10-15 10:26 |
If we refer to the large file summit, it may be useful to add: EOVERFLOW The file is a regular file and at least on of the time stamps cannot be represented correctly in an object of type time_t ...since this has been slipped in the large file summit: The LFS struct stat should have introduced a 64 bit time_t object as well. |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2019-10-06 15:54 | dennisw | New Issue | |
| 2019-10-06 15:54 | dennisw | Name | => Dennis Wölfing |
| 2019-10-06 15:54 | dennisw | Section | => tmpfile |
| 2019-10-06 15:54 | dennisw | Page Number | => 2162 |
| 2019-10-06 15:54 | dennisw | Line Number | => 69312-69313 |
| 2019-10-14 16:22 | Don Cragun | Note Added: 0004618 | |
| 2019-10-14 16:37 | Don Cragun | Note Edited: 0004618 | |
| 2019-10-14 20:30 | shware_systems | Note Added: 0004619 | |
| 2019-10-15 09:59 | geoffclare | Note Added: 0004621 | |
| 2019-10-15 10:01 | geoffclare | Note Edited: 0004621 | |
| 2019-10-15 10:25 | joerg | Note Added: 0004623 | |
| 2019-10-15 10:26 | joerg | Note Edited: 0004623 | |
| 2019-12-12 17:18 | geoffclare | Note Edited: 0004621 | |
| 2019-12-12 17:22 | Don Cragun | Interp Status | => --- |
| 2019-12-12 17:22 | Don Cragun | Status | New => Resolved |
| 2019-12-12 17:22 | Don Cragun | Resolution | Open => Accepted |
| 2019-12-12 17:22 | Don Cragun | Tag Attached: tc3-2008 | |
| 2019-12-17 16:20 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 09:08 | agadmin | Status | Applied => Closed |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
