This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
From: Ulrich Drepper <drepper@cygnus.com> Date: 30 Jun 1999 12:47:26 -0700 Andreas Jaeger <aj@arthur.rhein-neckar.de> writes: > I've checked POSIX and my understanding of POSIX is that the check for > NULL is necessary. POSIX says: If successful, the getpwuid_r() and getpwnam_r() functions shall return zero. Otherwise, an error number shall be returned to indicate the error. I.e., the return value is != 0 in all error cases and no found entry is an error case. Yep, but Andreas is talking about gethostbyname_r(). The case he illustrates with his example is the case where gethostbyname() sets h_errno to HOST_NOT_FOUND, but errno is not set. Therefore, gethostbyname_r() returns 0 and stores HOST_NOT_FOUND in h_errnop. So instead of checking both the return value and the value stored in h_errnop, Andreas suggests to check the result pointer. AFAIK gethostbyname_r() is not standardized by POSIX. If you look at the code in bind 8.2 (src/include/netdb.h) you see that there are two flavours of the various getXXbyYY_r functions. Solaris and BSDI return a pointer to the resul buffer on success (and NULL on some sort of failure, which sets errno or stores something in h_errnop). HPUX and OSF return -1 on error and use a special data structure to guarantee thread-safety. While looking into these things, I came across a message apparently written by one of the people who did the origional implementation of gethostbyname_r on Solaris, where he said that returning a pointer to the struct was a bit silly (since the same pointer is already stored in a location specified by the user) and that returning an error value would be the right thing to do (which is what we do for glibc right now). Mark
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |