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
0001624 [Issue 8 drafts] System Interfaces Comment Clarification Requested 2022-12-22 11:20 2023-01-19 17:20
Reporter romanzilka View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Resolved   Product Version Draft 2.1
Name Roman Žilka
Organization
User Reference
Section getdelim()
Page Number 1017-1019
Line Number 34871-34961
Final Accepted Text Note: 0006114
Summary 0001624: getdelim() / getline() non-success reporting clarification
Description getdelim() and getline() are required (Draft 2.1, Issue 7 / 2018) to, among other things, set the stream error indicator "if an error occurs". The errors defined include EINVAL, ENOMEM and EOVERFLOW. These are conditions unrelated to I/O on the stream and there may be doubt whether the function should actually set the ferror. The current glibc implementation, for instance, will not set it for EINVAL, nor possibly for the other two. Please, clarify either here or in the standard.
Desired Action I will leave this decision to the more experienced. As a user of these interfaces, I expect a deterministic means of finding out what happened when a call returns -1. If getdelim() is indeed supposed to set ferror (to make it short) on *all* errors, I can use ferror() / feof() to tell. If some errors only produce the -1 and an errno, but not ferror, I cannot tell for (feof() && ! ferror()), whether an error occurred as well and I can refer to errno. The example given for getline() in POSIX and the note about feof()/ferror() in Application Usage are thus not quite correct. They're incorrect, in fact, even for (! feof() && ! ferror()).

All this while I am assuming that the eof and ferror conditions are mutually exclusive. That is not explicitly stated anywhere in POSIX or C (not C99 anyway, that's the only one I have available), AFAIK, but the wording strongly suggests so in C99, 7.19.7.1 and in POSIX in the Application Usage in multiple functions. C literally mentions that "feof and ferror" can be used to tell the eof/ferror conditions apart, which sounds just a bit like one may need both, but let's suppose that either one is sufficient. POSIX talks about "ferror() or feof()", which leaves little space for doubt. Still, clarification may be in order in this matter, too.

Note, however, that this mutual exlusion may be impossible to maintain. A run of getdelim() may successfully read some data, advance to eof, so that feof()==true, and then encounter an error unrelated to I/O, e.g., ENOMEM allocating space for the '\0'. Another example is the eof condition at the very start of getline() while also EINVAL. A solution to the latter may be prioritizing an eof check before any error check in getline(), but that doesn't follow from POSIX and, once again, glibc won't do that.

Similar issues may be present in other stdio functions doing I/O on a stream. fgetc() seems to address the mut. ex. issue in saying outright in Description that an eof check is made prior to any reads. That's not sufficient, though, when other errors besides I/O ones can happen. Note also that fgetc() is required to set ferror if "a read error occurs", not just any error, as the section on getdelim() is putting it. One of the optional errors defined for fgetc() is ENOMEM, however, which brings us back to the beginning. Granted, I'm not sure how ENOMEM happens there.
Tags issue8
Attached Files

- Relationships

-  Notes
(0006114)
geoffclare (manager)
2023-01-19 17:19

On page 851 line 28924 section fgetc(), and
page 855 line 29054 section fgets(), and
page 859 line 29223 section fgetws(), and
page 945 line 32390 section fscanf(), change:
If a read error occurs, the error indicator for the stream shall be set, ...

to:
If an error occurs, the error indicator for the stream shall be set, ...


On page 857 line 29144 section fgetwc(), change:
If a read error occurs, the error indicator for the stream shall be set, ...

to:
If an error other than an encoding error occurs, the error indicator for the stream shall be set, ...


On page 857 line 29145 fgetwc(), change:
    
If an encoding error occurs, the error indicator for the stream shall be set, ...

to:
    
If an encoding error occurs, [CX]the error indicator for the stream shall be set,[/CX] ...


On page 858 line 29174 section fgetwc(), change RATIONALE from "None" to:
The requirement to set the error indicator when an encoding error occurs is shaded CX because this is not required by the ISO C standard. However, the next revision of the ISO C standard is expected to add this requirement.


On page 921 line 31501 section fread(), change:
The fread() function shall return the number of elements successfully read, which shall be less than nitems only if a read error or end-of-file is encountered. If size or nitems is 0, fread() shall return 0 and the contents of the array and the state of the stream remain unchanged. Otherwise, if a read error occurs, the error indicator for the stream shall be set, [CX]and errno shall be set to indicate the error.[/CX]

to:
The fread() function shall return the number of elements successfully read, which shall be less than nitems only if an error or end-of-file is encountered, or size is 0. If size or nitems is 0, fread() shall return 0 and the contents of the array and the state of the stream shall remain unchanged. Otherwise, if an error occurs, the error indicator for the stream shall be set, [CX]and errno shall be set to indicate the error.[/CX]

- Issue History
Date Modified Username Field Change
2022-12-22 11:20 romanzilka New Issue
2022-12-22 11:20 romanzilka Name => Roman Žilka
2022-12-22 11:20 romanzilka Section => getdelim()
2022-12-22 11:20 romanzilka Page Number => 1017-1019
2022-12-22 11:20 romanzilka Line Number => 34871-34961
2023-01-19 17:19 geoffclare Note Added: 0006114
2023-01-19 17:20 geoffclare Final Accepted Text => Note: 0006114
2023-01-19 17:20 geoffclare Status New => Resolved
2023-01-19 17:20 geoffclare Resolution Open => Accepted As Marked
2023-01-19 17:21 geoffclare Tag Attached: issue8


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