public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/1969] New: getgrnam() should return an unmodified errno not ENOENT
@ 2005-12-02 15:42 burnus at gmx dot de
  2005-12-02 15:57 ` [Bug libc/1969] " drepper at redhat dot com
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: burnus at gmx dot de @ 2005-12-02 15:42 UTC (permalink / raw)
  To: glibc-bugs

getgrname() returns a POINTER, which should be NULL for no entry and for error.

According to posix, errno is set if an error occures. Since error and not found
are listed separately, a not existing entry is not an error and errno shall not
be modified.

GNU C Library stable release version 2.3.5 (20050802)
returns errno = ENOENT.

According to POSIX 2003:

"The getgrnam() function shall return a pointer to a struct group with the
structure defined in <grp.h> with a matching entry if one is found. The
getgrnam() function shall return a null pointer if either the requested entry
was not found, or an error occurred. On error, errno shall be set to indicate
the error."

The only error messages listed in SUVv3 for getgrnam are:
"[EIO]
    An I/O error has occurred.
[EINTR]
    A signal was caught during getgrnam().
[EMFILE]
    {OPEN_MAX} file descriptors are currently open in the calling process.
[ENFILE]
    The maximum allowable number of files is currently open in the system."

-- 
           Summary: getgrnam() should return an unmodified errno not ENOENT
           Product: glibc
           Version: 2.3.5
            Status: NEW
          Severity: minor
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: burnus at gmx dot de
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: Compiled on a Linux 2.6.12 system on 2005-09-09.
  GCC host triplet: SUSE Linux 10.0 (i386) with kernel 2.6.14-
                    20051028140608-default
GCC target triplet: Configured for i686-suse-linux.


http://sourceware.org/bugzilla/show_bug.cgi?id=1969

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libc/1969] getgrnam() should return an unmodified errno not ENOENT
  2005-12-02 15:42 [Bug libc/1969] New: getgrnam() should return an unmodified errno not ENOENT burnus at gmx dot de
@ 2005-12-02 15:57 ` drepper at redhat dot com
  2005-12-02 16:59 ` burnus at gmx dot de
  2005-12-02 17:05 ` drepper at redhat dot com
  2 siblings, 0 replies; 4+ messages in thread
From: drepper at redhat dot com @ 2005-12-02 15:57 UTC (permalink / raw)
  To: glibc-bugs


------- Additional Comments From drepper at redhat dot com  2005-12-02 15:57 -------
There is nothing wrong with the implementation.  The code always did signal a
missing entry with a NULL pointer and ENOENT.  There is nothing in POSIX which
prohibits this.  The POSIX spec just said what has to happen for the error
conditions.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=1969

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libc/1969] getgrnam() should return an unmodified errno not ENOENT
  2005-12-02 15:42 [Bug libc/1969] New: getgrnam() should return an unmodified errno not ENOENT burnus at gmx dot de
  2005-12-02 15:57 ` [Bug libc/1969] " drepper at redhat dot com
@ 2005-12-02 16:59 ` burnus at gmx dot de
  2005-12-02 17:05 ` drepper at redhat dot com
  2 siblings, 0 replies; 4+ messages in thread
From: burnus at gmx dot de @ 2005-12-02 16:59 UTC (permalink / raw)
  To: glibc-bugs


------- Additional Comments From burnus at gmx dot de  2005-12-02 16:59 -------
> There is nothing wrong with the implementation.
I disagree.

> The code always did signal a missing entry with a NULL pointer and ENOENT.
Which does not say that this is POSIX conform. 

> There is nothing in POSIX which prohibits this. The POSIX spec just said what
> has to happen for the error conditions.
I agree that it only strongly implies that errno == 0 and that it does not
completely rule out return values != 0.
I opened an Aardvark to let the Austin Group clarify this in the next revision.

I only want to point out that there are others which read POSIX the same way as
I do (from the austin-group mailing list):

"Considering the application usage on P520, L17147-17148, my
expectation would be that if no error occurs but an entry is not found,
getgrnam() returns a null pointer while getgrnam_r() returns zero and
sets the pointer pointed to by result to a null pointer and that
neither getgrnam() nor getgrnam_r() would change errno in this case.
If an error occurred, the return value is the same but errno is also
set to indicate which error was detected."
https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=8929

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


http://sourceware.org/bugzilla/show_bug.cgi?id=1969

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libc/1969] getgrnam() should return an unmodified errno not ENOENT
  2005-12-02 15:42 [Bug libc/1969] New: getgrnam() should return an unmodified errno not ENOENT burnus at gmx dot de
  2005-12-02 15:57 ` [Bug libc/1969] " drepper at redhat dot com
  2005-12-02 16:59 ` burnus at gmx dot de
@ 2005-12-02 17:05 ` drepper at redhat dot com
  2 siblings, 0 replies; 4+ messages in thread
From: drepper at redhat dot com @ 2005-12-02 17:05 UTC (permalink / raw)
  To: glibc-bugs


------- Additional Comments From drepper at redhat dot com  2005-12-02 17:05 -------
Stop reopening bugs.  What desease is this?  Whether you agree or not does not
matter.  The code is correct.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=1969

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-12-02 17:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-12-02 15:42 [Bug libc/1969] New: getgrnam() should return an unmodified errno not ENOENT burnus at gmx dot de
2005-12-02 15:57 ` [Bug libc/1969] " drepper at redhat dot com
2005-12-02 16:59 ` burnus at gmx dot de
2005-12-02 17:05 ` drepper at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).