View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00014471003.1(2016/18)/Issue7+TC2System Interfacespublic2021-01-31 22:512021-11-04 16:16
Reporterkre Assigned To 
PrioritynormalSeverityObjectionTypeOmission
Status ClosedResolutionRejected 
NameRobert Elz
Organization
User Reference
SectionXSH 3 / fread; XSH 3 / fwrite; (maybe more)
Page Number931, 1001
Line NumberNone specifically, this is an omission...
Interp Status---
Final Accepted Text
Summary0001447: fread()/fwrite() (maybe more similar) specify no requirements on args
DescriptionThis may be something that ought to be sent to the C standard committee, I will
leave that for others to determine.

As specified, neither fread() nor frwite() say anything at all about what
is required of their arguments - except perhaps for the stream arg, via the
list of errors from fgetc()/fputc() which are incorporated by reference.

In particular, while it is stated that the results for fread() or data
written for frwite() come from an unsigned char array that overlays the
data struct (*ptr), and it is implied that array is nitems * size bytes large
(never actually stated, but one can conclude that from the description)
there's no statement that the user's provided buffer actually needs to be
that big.

That is, if that is even possible to achieve, each of size and nitems is a
size_t, hence each (alone) is large enough to represent the largest possible
object that can exist - multiply them together and (unless at least one of
them is 0 or 1) it is possible to overflow the biggest possible object size,
and even if it is possible to write that much data, it cannot be done in an
overlayed char array (which being a single object must have a size that can
be represented in a size_t).
Desired ActionAdd words to specify requirements on the args.

That is, ptr must point at a buffer which is at least nitems * size bytes
large, and nitems * size must not overflow a size_t.

The first is not possible for the functions to check, so that one must
simply be a requirement on the application, but the functions can validate
that nitems * size does not overflow, and I believe some implementations
check that, and return EINVAL if it happens.

Add EINVAL to the list of possible errors. EFAULT is probably also needed
- though some implementations probably SEGV instead of returning EFAULT,
it depends whether the implementation actually does a large sequence of
fgets/fputc calls, or whether it simply calls read() (or write()) and then
manipulates the stream data struct to handle that. These are errors that
don't occur from fgets()/fputc().
TagsNo tags attached.

Activities

Don Cragun

2021-11-04 16:16

manager   bugnote:0005517

Any attempt to read or write data beyond the end of an object is undefined behavior. How the attempt is made is irrelevant - calling a function with a buffer and a size larger than the buffer is one way; calling a function with a buffer, an element size, and a number of elements, where the buffer is not large enough to hold that many elements is another.

The standard already permits implementations to fail with EFAULT on any interface as an extension (it's something we have explicitly chosen not to standardize, however, as detecting memory faults is not portable to all hardware).

Issue History

Date Modified Username Field Change
2021-01-31 22:51 kre New Issue
2021-01-31 22:51 kre Name => Robert Elz
2021-01-31 22:51 kre Section => XSH 3 / fread; XSH 3 / fwrite; (maybe more)
2021-01-31 22:51 kre Page Number => 931, 1001
2021-01-31 22:51 kre Line Number => None specifically, this is an omission...
2021-11-04 16:16 Don Cragun Interp Status => ---
2021-11-04 16:16 Don Cragun Note Added: 0005517
2021-11-04 16:16 Don Cragun Status New => Closed
2021-11-04 16:16 Don Cragun Resolution Open => Rejected