A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1220
==
Reported By:bhaible
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=697
==
Reported By:steffen
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=697
==
Reported By:steffen
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=697
==
Reported By:steffen
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1220
==
Reported By:bhaible
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=697
==
Reported By:steffen
Assigned To:
Geoff Clare wrote:
> 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
> --
> (0005036) shware_systems (reporter) - 2020-10-07 14:28
> https://austingroupbugs.net/view.php?id=697#c5036
> --
> That is an error in read(), and
The C standard leaves it undefined for fread() because it doesn't require
EOVERFLOW in , 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