Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001830 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Enhancement Request 2024-05-03 06:55 2024-05-13 09:10
Reporter lacos View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name László Érsek
Organization
User Reference
Section pwrite, write
Page Number ?
Line Number ?
Interp Status ---
Final Accepted Text
Summary 0001830: off-by-one error regarding offset maximum
Description (Sorry for not providing page and line numbers; I've not been following POSIX development for a good while, and don't remember where I could download a PDF version.)

The open() specification contains:

"The largest value that can be represented correctly in an object of type off_t shall be established as the offset maximum in the open file description."

The write() / pwrite() spec states the following, *consistently* with the open() spec:

"""
[EFBIG]
    The file is a regular file, nbyte is greater than 0, and the starting position is greater than or equal to the offset maximum established in the open file description associated with fildes.
"""

However, the write() / pwrite() spec also states the following, *inconsistently* with the above references:

"For regular files, no data transfer shall occur past the offset maximum established in the open file description associated with fildes."

This last statement is not strict enough; a data transfer even precisely *at* the offset maximum, not just past it, should not occur. Otherwise, the resultant offset will not be representable in off_t.

Footnote 1: for simplicity, assume that off_t is identical to int8_t; in that case, the off_t maximum, hence the offset maximum, is 127. If we allowed

  lseek(fd, 127, SEEK_SET);
  write(fd, "X", 1);

to succeed, then the next call to

  lseek(fd, 0, SEEK_CUR);

would have to fail with -1/EOVERFLOW. The EFBIG description in write() actually forbids the above write() from succeeding -- correctly so --, however the "no data transfer shall occur past the offset maximum" language would permit this write() to succeed (because the data transfer would occur precisely *at* the offset maximum), and that's what's wrong.)

Footnote 2: this is an interesting difference from pointer arithmetic in the C standard. In, C, the following is valid:

  char x[10];
  char *p;

  p = x + 9;
  *p++ = 'X';
  p;

That is, pointing one past the array is valid -- evaluating such a pointer is valid (while dereferencing it is undefined behavior). In contrast, with the file position, we cannot point one past the max representable off_t, and therefore we cannot transfer to/from the byte in the file *at* the max representable off_t.
Desired Action In write()/pwrite(), change

"For regular files, no data transfer shall occur past the offset maximum established in the open file description associated with fildes."

to

"For regular files, no data transfer shall occur at or past the offset maximum established in the open file description associated with fildes."
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0006778)
geoffclare (manager)
2024-05-13 09:10

 This seems to be a difference in understanding of what the standard means when it refers to data transfer past a given offset.

My understanding matches the way I believe that the author(s) of that text intended it to be read. Taking the example of offset 127, to me this code:

lseek(fd, 127, SEEK_SET);
write(fd, "X", 1);

results in data transfer past the offset 127, because the new offset is 128 which is greater than 127.

It appears that other people understand the phrase differently.

This should be solved by changing the phrasing to something that can't be understood in different ways. For example:
For regular files, no data transfer shall occur that would result in the file offset being set to a value greater than the offset maximum established in the open file description associated with fildes.

- Issue History
Date Modified Username Field Change
2024-05-03 06:55 lacos New Issue
2024-05-03 06:55 lacos Name => László Érsek
2024-05-03 06:55 lacos Section => pwrite, write
2024-05-03 06:55 lacos Page Number => ?
2024-05-03 06:55 lacos Line Number => ?
2024-05-13 09:10 geoffclare Note Added: 0006778

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