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
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

- Relationships

-  Notes
(0000970)
Don Cragun (manager)
2011-09-22 16:07

Interpretation response
------------------------

The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.

Rationale:
-------------
These sets of interfaces should act consistently.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
Make the changes suggested in the Desired Action.
(0001299)
ajosey (manager)
2012-06-29 16:18

Interpretation proposed 29 June 2012 for final 45 day review
(0001340)
ajosey (manager)
2012-08-30 09:10

Interpretation approved 30 Aug 2012

- 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
Powered by Mantis Bugtracker