Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001447 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Omission 2021-01-31 22:51 2021-11-04 16:16
Reporter kre View Status public  
Assigned To
Priority normal Resolution Rejected  
Status Closed  
Name Robert Elz
User Reference
Section XSH 3 / fread; XSH 3 / fwrite; (maybe more)
Page Number 931, 1001
Line Number None specifically, this is an omission...
Interp Status ---
Final Accepted Text
Summary 0001447: fread()/fwrite() (maybe more similar) specify no requirements on args
Description This 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 Action Add 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().
Tags No tags attached.
Attached Files

- Relationships

-  Notes
Don Cragun (manager)
2021-11-04 16:16

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

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker