 Relationships |
|
| Anonymous | Login | 2023-10-03 01: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 | ||
| 0001624 | [Issue 8 drafts] System Interfaces | Comment | Clarification Requested | 2022-12-22 11:20 | 2023-03-10 10:50 | ||
| Reporter | romanzilka | View Status | public | ||||
| Assigned To | |||||||
| Priority | normal | Resolution | Accepted As Marked | ||||
| Status | Applied | 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 | |
| 2023-03-10 10:50 | geoffclare | Status | Resolved => Applied |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
