Austin Group Defect Tracker

Aardvark Mark IV


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 2019-12-17 16:20
Reporter dennisw View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Applied  
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
in an object of type off_t.
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:

[EOVERFLOW]
The named file is a regular file and the size of the file cannot be represented correctly in an object of type off_t.

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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker