The C standard leaves it undefined for fread() because it doesn't require EOVERFLOW in <errno.h>, that I see, or presumes size_t will always be a short or int type. Since POSIX does have it and does not presume a limited width I feel this is a place where a CX extension is warranted as a portability consideration. On Wednesday, October 7, 2020 Geoff Clare via austin-group-l at The Open Group <g...@opengroup.org> wrote: > ---------------------------------------------------------------------- > (0005036) shware_systems (reporter) - 2020-10-07 14:28 > https://austingroupbugs.net/view.php?id=697#c5036 > ---------------------------------------------------------------------- > That is an error in read(), and fread() as well; that these should have > that case also as a may fail type.
The above was in reply to my note about posix_getdents() EOVERFLOW that said: This set me thinking about why that part of the EOVERFLOW error is there at all. There is no equivalent EOVERFLOW for read(), nor should there be. I continue to believe that for read() there should not be an EOVERFLOW error. There is absolutely no reason for read() to fail when it could instead successfully return SSIZE_MAX bytes. Perhaps we should add a statement: If <i>nbyte</i> is great than SSIZE_MAX, <i>read</i>() shall behave as if <i>nbyte</i> had the value SSIZE_MAX. For fread(), the return type is size_t not ssize_t, so it doesn't have quite the same problem. The question is what should happen if the mathematical product of the size and nitems arguments is greater than SIZE_MAX. POSIX defers to the C standard on this and there is no reason for us to state anything specific about it. (The C standard is silent on the matter, so the behaviour is implicitly undefined.) -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
