Notes |
(0002439)
dalias (reporter)
2014-11-22 03:43
|
These functions are all specified by ISO C, so any deficiency in the specification should probably be addressed with WG14. However, I believe all of these issues are already covered adequately by the current wording. Read and write operations on stdio streams take place as if by repeated calls to fgetc or fputc. If any of those fgetc or fputc calls would produce an error, it's generally an error for the whole operation. EOF is not a failure unless it's specified to be (certain functions don't "succeed" if no data is read, for instance).
These conditions are detailed in the documentation for individual functions too. For example, the fgets function is specified to stop upon reading n-1 bytes, or a newline, or end of file. Any of these conditions is "success", except the special case of immediately hitting EOF, which is noted. The return value on success is clearly defined, along with this special case (EOF with no data) and the error cases. |
|
(0002440)
safinaskar (reporter)
2014-11-22 19:23
|
> These functions are all specified by ISO C, so any deficiency in the specification should probably be addressed with WG14
Okey, let's talk about C standard (C99). :)
C99 is more clear than POSIX, but still has issues.
C99 clearly says in the beginning of <stdio.h> section that EOF indicator is always set on EOF and error indicator is always set on error (unlike POSIX). :) And this is very good.
So, mentions of this indicators are not needed in particular functions descriptions. Also, C99 doesn't specify whatever errno is set on errors in this functions, so errno mentions are not needed, too. So, all C99 should say in functions descriptions is what functions return. And C99 almost fully done this simple task. :)
*printf, *scanf, fread, fwrite, fputs, puts functions are OK in C99. fgets section doesn't say what is "success" and so doesn't say what the function return on partial read due to EOF.
So, please redirect this fgets issue to WG14. ^_^
Now, let's talk about POSIX (2013 issue).
> Read and write operations on stdio streams take place as if by repeated calls to fgetc or fputc
POSIX says in XSH 2.5 that all stdio.h I/O is performed as if it was implemented using fgetc/fputc. And I didn't notice this at first. This makes some things clearer, thanks. But how I supposed to find this sentence? Functions themselves don't refer to XSH 2.5. So, please, make this referring.
> If any of those fgetc or fputc calls would produce an error, it's generally an error for the whole operation
How I supposed to know this from POSIX spec? Also, there is opposite precedent in POSIX spec: "read" and "write" functions. If you start some read/write operation, this operation reads/writes some bytes and then you interrupt the process with some signal (handler for this signal should be set), then this read/write will not fail with EINTR, it will instead successfully return you number of read/written bytes. (Am I right?) So this precedent suggests that stdio.h should behave the same. So, why I should think that stdio.h behave opposite way? Where should I know this?
> EOF is not a failure unless it's specified to be (certain functions don't "succeed" if no data is read, for instance).
Again, where I should know this?
> Any of these conditions is "success", except the special case of immediately hitting EOF, which is noted.
Where I should know that this three conditions are success? "If the stream is at end-of-file..." - okey, let's assume this means "stream is at end-of-file BEFORE running of fgets", but this is still bad phrase.
Now, let me repeat issues with (as an example) fgets in POSIX.
What means "success"? What of the following conditions are "success"?
A. n - 1 bytes have read
B. delimeter (i. e. new line) reached
C. EOF reached after some bytes
D. EOF reached at start
E. error after some bytes
(I will not put here "F. error at start", because this is clearly failure, all other cases may be threaded as "success")
"If the stream is at end-of-file" - what this means? Any EOF during fgets? Or EOF only at start of fgets? Okey, now I see this means "EOF at start", but it was very hard to me to understand the phrase this way, so I think it still needs rewriting. |
|
(0002441)
dalias (reporter)
2014-11-22 20:52
|
The text about behaving as if by repeated fgetc/fputc is also in ISO C. The issue of having to read the introductory text rather than simply finding this copied in the description of each function also exists in ISO C, and it seems unlikely to change there.
EINTR is specified as an error condition for both fgetc and fputc (see the "shall fail" text). They do not retry on EINTR, and therefore the "aggregate stdio functions" built on fgetc/fputc do not retry but see and report the error. For some functions (fread and fwrite), a read or write error is specified to cause them to return a "short read" or "short write"; for others; an error value (typically NULL or EOF) is returned. This is documented for each individual function.
For when EOF is a failure, see the individual functions. scanf fails if EOF is reached without converting any items, but this is not an "error" in the sense of something that needs to set errno (because it's not one of the "shall fail" conditions); it's just one of the possible results.
For fgets, A, B, and C are "success". D could also be seen as "success" (it's not an error since it's not covered in the "shall fail" text) but it's handled specially anyway under "return value".
In any case, there is a lot of language in the standards whose meaning is not entirely obvious until you take the time to study it. This is generally inevitable. Writing a formal specification that reflects existing practice is hard work, and the more details you add, the more room there is or mistakes and unintended contradictions. I do think it would be possible to make the text for these functions much more clear and understandable, but it would require extraordinary amounts of work to ensure that the new text has the exact same meaning as the old text, and I think it would be hard to justify such a project. On the other hand, adding non-normative clarifying text under "application usage" for these functions could be practical and may be worthwhile. But if you want this to happen, you probably need to propose such text, or find someone else willing to write a proposal. |
|
(0002442)
safinaskar (reporter)
2014-11-22 23:26
|
Well, okey... :( Please, somebody, close this bug. But if someone fix mentioned issues I will be happy :) |
|