 Relationships |
||||||
|
||||||
| Anonymous | Login | 2024-04-18 05:10 UTC |
| 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 | ||
| 0000343 | [1003.1(2008)/Issue 7] System Interfaces | Objection | Error | 2010-10-28 20:15 | 2013-04-16 13:06 | ||
| Reporter | eblake | View Status | public | ||||
| Assigned To | ajosey | ||||||
| Priority | normal | Resolution | Accepted As Marked | ||||
| Status | Closed | ||||||
| Name | Eric Blake | ||||||
| Organization | Red Hat | ||||||
| User Reference | ebb.ftok | ||||||
| Section | ftok | ||||||
| Page Number | 958 | ||||||
| Line Number | 32098 | ||||||
| Interp Status | Approved | ||||||
| Final Accepted Text | See Note: 0000627 | ||||||
| Summary | 0000343: ftok cleanups | ||||||
| Description |
ftok() requires that the path argument be something that the process can stat(). However, stat() has a mandatory EIO failure omitted in ftok(). stat() also has a mandatory EOVERFLOW scenario (if the program was not compiled for large file support), but any implementation where EOVERFLOW can occur should have an internal counterpart function (such as stat64) which should be used by the ftok() implementation, so ftok correctly avoids listing EOVERFLOW. Additionally, the examples section for ftok() is redundant, as there is no significant difference between the two examples. |
||||||
| Desired Action |
After line 32100 [XSH ftok ERRORS], add a new paragraph: [EIO] An error occurred while reading from the file system. Delete lines 32119-32128 [XSH ftok EXAMPLES] (the body of the first example, and the title of the second), leaving just the second example under the title "Getting an IPC Key". |
||||||
| Tags | tc1-2008 | ||||||
| Attached Files | |||||||
|
|
|||||||
|
Relationships |
||||||
|
||||||
|
Notes |
|
|
(0000595) geoffclare (manager) 2010-10-29 08:52 edited on: 2010-10-29 15:19 |
The requirement "The application shall ensure that the path argument is the pathname of an existing file that the process is able to stat()" includes a requirement on the application to ensure that a stat() call on the file would not produce an EOVERFLOW error. If we want to require ftok() to be usable on files for which stat() would give EOVERFLOW, we need to say so explicitly. |
|
(0000625) eblake (manager) 2010-12-01 04:34 |
I surveyed several 32-bit systems to see how ftok() behaves in practice. Most BSD-based systems these days (FreeBSD, MacOS, Cygwin) only support ILP32_OFFBIG as their default compiler offering, with no way to compile for ILP32_OFF32, at least as confirmed by getconf. Likewise, 64-bit platforms tend to never encounter EOVERFLOW with stat, because long is already 64 bits. Linux and Solaris 10 were the only 32-bit platforms I had access to where both ILP32_OFF32 and ILP32_OFFBIG environments existed, and the following program gave me similar results on both platforms (where ftok() succeeds even when stat() fails): $ cat foo.c #include <sys/ipc.h> #include <stdio.h> #include <sys/stat.h> #include <string.h> #include <errno.h> int main (int argc, char **argv) { if (argc <= 1) { puts ("usage: foo file"); return 1; } printf ("sizeof long %zu, sizeof off_t %zu\n", sizeof (long), sizeof (off_t)); struct stat sb; int i = stat (argv[1], &sb); if (i == -1) printf ("stat failed: %d %s\n", errno, strerror (errno)); else puts ("stat succeeded"); key_t k = ftok (argv[1], 'a'); if (k == (key_t) -1) printf ("ftok failed: %d %s\n", errno, strerror (errno)); else printf ("ftok returned %d\n", (int) k); return 0; } $ truncate --size 5G sparse # from GNU coreutils $ cc foo.c -o foo32 $(getconf POSIX_V6_ILP32_OFF32_CFLAGS) $ cc foo.c -o foo64 $(getconf POSIX_V6_ILP32_OFFBIG_CFLAGS) $ ./foo32 sparse sizeof long 4, sizeof off_t 4 stat failed: 79 Value too large for defined data type ftok returned 1627565399 $ ./foo64 sparse sizeof long 4, sizeof off_t 8 stat succeeded ftok returned 1627565399 Therefore, it should be safe to amend the proposal to explicitly require that ftok() cannot fail due to EOVERFLOW (implementations that distinguish between stat() and an internal stat64() for supporting both environments merely need ensure that ftok() uses stat64()). |
|
(0000626) geoffclare (manager) 2010-12-01 15:47 |
I tried Eric's program on an HP-UX 11 system, and got the same results: $ file foo32 foo32: ELF-32 executable object file - IA64 $ file foo64 foo64: ELF-64 executable object file - IA64 $ ./foo32 sparse sizeof long 4, sizeof off_t 4 stat failed: 72 Value too large to be stored in data type ftok returned 1628438554 $ ./foo64 sparse sizeof long 8, sizeof off_t 8 stat succeeded ftok returned 1628438554 |
|
(0000627) eblake (manager) 2010-12-02 15:50 edited on: 2010-12-02 16:16 |
Interpretation response ------------------------ The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- None. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- At line 32087 [XSH ftok DESCRIPTION], change "existing file that the process is able to stat()" to: existing file that the process is able to stat(), with the exception that if stat() would fail with EOVERFLOW due to file size, ftok() shall still succeed. After line 32100 [XSH ftok ERRORS], add a new paragraph: [EIO] An error occurred while reading from the file system. Delete lines 32119-32128 [XSH ftok EXAMPLES] (the body of the first example, and the title of the second), leaving just the second example under the title "Getting an IPC Key". |
|
(0000638) ajosey (manager) 2010-12-16 16:14 |
Comments are due on this interpretation by January 16 2011 |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2010-10-28 20:15 | eblake | New Issue | |
| 2010-10-28 20:15 | eblake | Status | New => Under Review |
| 2010-10-28 20:15 | eblake | Assigned To | => ajosey |
| 2010-10-28 20:15 | eblake | Name | => Eric Blake |
| 2010-10-28 20:15 | eblake | Organization | => Red Hat |
| 2010-10-28 20:15 | eblake | User Reference | => ebb.ftok |
| 2010-10-28 20:15 | eblake | Section | => ftok |
| 2010-10-28 20:15 | eblake | Page Number | => 958 |
| 2010-10-28 20:15 | eblake | Line Number | => 32098 |
| 2010-10-28 20:15 | eblake | Interp Status | => --- |
| 2010-10-29 08:52 | geoffclare | Note Added: 0000595 | |
| 2010-10-29 09:02 | geoffclare | Note Added: 0000596 | |
| 2010-10-29 09:03 | geoffclare | Note Deleted: 0000596 | |
| 2010-10-29 14:58 | eblake | Desired Action Updated | |
| 2010-10-29 15:19 | geoffclare | Note Edited: 0000595 | |
| 2010-12-01 04:34 | eblake | Note Added: 0000625 | |
| 2010-12-01 15:47 | geoffclare | Note Added: 0000626 | |
| 2010-12-02 15:50 | eblake | Note Added: 0000627 | |
| 2010-12-02 16:11 | eblake | Note Edited: 0000627 | |
| 2010-12-02 16:16 | nick | Note Edited: 0000627 | |
| 2010-12-02 16:17 | nick | Interp Status | --- => Pending |
| 2010-12-02 16:17 | nick | Final Accepted Text | => See Note: 0000627 |
| 2010-12-02 16:17 | nick | Status | Under Review => Interpretation Required |
| 2010-12-02 16:17 | nick | Resolution | Open => Accepted As Marked |
| 2010-12-02 16:18 | nick | Tag Attached: tc1-2008 | |
| 2010-12-16 16:14 | ajosey | Interp Status | Pending => Proposed |
| 2010-12-16 16:14 | ajosey | Note Added: 0000638 | |
| 2011-01-18 12:30 | ajosey | Interp Status | Proposed => Approved |
| 2011-04-22 10:44 | eblake | Relationship added | related to 0000366 |
| 2013-04-16 13:06 | ajosey | Status | Interpretation Required => Closed |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
