Anonymous | Login | 2024-03-29 11:03 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 | ||
0000493 | [1003.1(2008)/Issue 7] System Interfaces | Objection | Clarification Requested | 2011-09-09 15:42 | 2019-06-10 08:55 | ||
Reporter | geoffclare | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted | ||||
Status | Closed | ||||||
Name | Geoff Clare | ||||||
Organization | The Open Group | ||||||
User Reference | |||||||
Section | endpwent | ||||||
Page Number | 755 | ||||||
Line Number | 25259, 25268 | ||||||
Interp Status | Approved | ||||||
Final Accepted Text | See note Note: 0000970 | ||||||
Summary | 0000493: Behaviour of getpwent() after endpwent() is not clear | ||||||
Description |
The descriptions of the endpwent() and getpwent() functions do not make sufficiently clear what happens when getpwent() is called after an endpwent() call. For endpwent() it says: "The endpwent() function may be called to close the user database when processing is complete." As a minimum the "may" should change to "can", but it would be better to word this as a clear requirement on the implementation. There is a clearer statement in the example ("The call to endpwent() closes the user database and cleans up"), but it's non-normative text and so doesn't constitute a requirement on the implementation. For getpwent() it says: "When first called, getpwent() shall return a pointer to a passwd structure containing the first entry in the user database. Thereafter, it shall return a pointer to a passwd structure containing the next entry in the user database. Successive calls can be used to search the entire user database." By a strict reading, the condition "when first called" only applies to the first call made by a program. It should also apply to the first call after an endpwent() call. Contrast these with the endutxent() page, which contains these statements: "The getutxent() function shall read the next entry from the user accounting database. If the database is not already open, it shall open it." and: "The endutxent() function shall close the user accounting database." In addition, the ERRORS section includes errors for setpwent() and endpwent(), but their descriptions do not say how errors are indicated. Finally, the description of setpwent() needs to use "shall". The endgrent() page has similar problems. There are also some inconsistencies between the endpwent() and endgrent() pages in the RETURN VALUE and ERRORS sections. I have attempted to reconcile these by proposing some changes on both pages. |
||||||
Desired Action |
At line 25259 change: When first called, getpwent() shall return a pointer to a passwd structure containing the first entry in the user database. to: If the user database is not already open, getpwent() shall open it and return a pointer to a passwd structure containing the first entry in the database. At line 25267 change: The setpwent() function effectively rewinds the user database to allow repeated searches. to: The setpwent() function shall rewind the user database so that the next getpwent() call returns the first entry, allowing repeated searches. At line 25268 change: The endpwent() function may be called to close the user database when processing is complete. to: The endpwent() function shall close the user database. The setpwent() and endpwent() functions shall not change the setting of errno if successful. On error, the setpwent() and endpwent() functions shall set errno to indicate the error. Since no value is returned by the setpwent() and endpwent() functions, an application wishing to check for error situations should set errno to 0, then call the function, then check errno. At line 25271 change: The getpwent() function shall return a null pointer on end-of-file or error. to: On successful completion, getpwent() shall return a pointer to a passwd structure. On end-of-file, getpwent() shall return a null pointer and shall not change the setting of errno. On error, getpwent() shall return a null pointer and errno shall be set to indicate the error. Insert before line 25274 (the EIO error): [EINTR] A signal was caught during the operation. At page 747 line 25044 section endgrent() change: When first called, getgrent() shall return a pointer to a group structure containing the first entry in the group database. to: If the group database is not already open, getgrent() shall open it and return a pointer to a group structure containing the first entry in the database. At line 25053 change: The setgrent() function shall rewind the group database to allow repeated searches. to: The setgrent() function shall rewind the group database so that the next getgrent() call returns the first entry, allowing repeated searches. At line 25054 change: The endgrent() function may be called to close the group database when processing is complete. to: The endgrent() function shall close the group database. The setgrent() and endgrent() functions shall not change the setting of errno if successful. On error, the setgrent() and endgrent() functions shall set errno to indicate the error. Since no value is returned by the setgrent() and endgrent() functions, an application wishing to check for error situations should set errno to 0, then call the function, then check errno. At line 25057 change: When first called, getgrent() shall return a pointer to the first group structure in the group database. Upon subsequent calls it shall return the next group structure in the group database. The getgrent() function shall return a null pointer on end-of-file or an error and errno may be set to indicate the error. to: On successful completion, getgrent() shall return a pointer to a group structure. On end-of-file, getgrent() shall return a null pointer and shall not change the setting of errno. On error, getgrent() shall return a null pointer and errno shall be set to indicate the error. At line 25064 change: The getgrent() function may fail if: [EINTR] A signal was caught during the operation. [EIO] An I/O error has occurred. to: These functions may fail if: [EINTR] A signal was caught during the operation. [EIO] An I/O error has occurred. In addition, getgrent() and setgrent() may fail if: |
||||||
Tags | tc2-2008 | ||||||
Attached Files | |||||||
|
Issue History | |||
Date Modified | Username | Field | Change |
2011-09-09 15:42 | geoffclare | New Issue | |
2011-09-09 15:42 | geoffclare | Status | New => Under Review |
2011-09-09 15:42 | geoffclare | Assigned To | => ajosey |
2011-09-09 15:42 | geoffclare | Name | => Geoff Clare |
2011-09-09 15:42 | geoffclare | Organization | => The Open Group |
2011-09-09 15:42 | geoffclare | Section | => endpwent |
2011-09-09 15:42 | geoffclare | Page Number | => 755 |
2011-09-09 15:42 | geoffclare | Line Number | => 25259, 25268 |
2011-09-09 15:42 | geoffclare | Interp Status | => --- |
2011-09-22 16:07 | Don Cragun | Note Added: 0000970 | |
2011-09-22 16:09 | Don Cragun | Interp Status | --- => Pending |
2011-09-22 16:09 | Don Cragun | Final Accepted Text | => See note Note: 0000970 |
2011-09-22 16:09 | Don Cragun | Status | Under Review => Interpretation Required |
2011-09-22 16:09 | Don Cragun | Resolution | Open => Accepted |
2011-09-22 16:09 | Don Cragun | Description Updated | |
2011-09-22 16:09 | Don Cragun | Desired Action Updated | |
2011-09-22 16:09 | Don Cragun | Tag Attached: tc2-2008 | |
2012-06-29 16:18 | ajosey | Interp Status | Pending => Proposed |
2012-06-29 16:18 | ajosey | Note Added: 0001299 | |
2012-08-30 09:10 | ajosey | Interp Status | Proposed => Approved |
2012-08-30 09:10 | ajosey | Note Added: 0001340 | |
2019-06-10 08:55 | agadmin | Status | Interpretation Required => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |