Re: Why this strange change?

[Mark Kettenis <kettenis@wins.uva.nl>]

   Date: Sun, 27 Jun 1999 21:55:32 -0700 (PDT)
   From: hjl@lucon.org (H.J. Lu)

   Hi, Ulrich,

   Your change

   1999-06-17  Ulrich Drepper  <drepper@cygnus.com>

	   * nss/getXXbyYY_r.c: Return error code not -1. 
	   * nss/getXXent_r.c: Likewise.

   breaks glibc and Linux very badly. Any codes like

	   if (getXXbyYY_r (......) < 0)

   now don't work anymore since now getXXbyYY_r () returns errno which is
   a positive number. Did you mean to return NAGATIVE of the error code?
   Could you please double check all of your similar changes and fix them?

   BTW, even if you can change all of

	   if (getXXbyYY_r (......) < 0)

   in glibc, how do you change all the user codes? I am not sure it is a
   good idea to make a change like that. You changed ABI in fact.

Not for getpw*_r and getgr*_r.  The documentation (for getpwuid_r) says:

     If the return value is `0' the pointer returned in RESULT points
     to the record which contains the wanted data (i.e., RESULT
     contains the value RESULT_BUF).  If it is nonzero, there is no
     user in the data base with user ID UID, or the buffer BUFFER is
     too small to contain all the needed information.  In the latter
     case, ERRNO is set to `ERANGE'.

While this doesn't say that getpwuid_r will return an error value,
doing so is perfectly OK since any nonzero return value indicates an
error of some sorts.  All we have to do to maintain binary
compatibility with previous glibc versions, is keep setting ERRNO to
`ERANGE' for buffer overflow (and of course use ERANGE as the return
value as well), and not touching it at all in all other cases.

Of course we should adapt the documentation to indicate that these
functions now return an error value.

The other getXXbyYY_r functions (for example gethostbyname_r) not
documented at all, and I haven't seen any standards that mention these
yet (Ulrich, does POSIX.1b really define these other functions?).
IMHO this means they're not part of any ABI, so we can't be breaking
the ABI.  One could argue that these function are analogous to the
getpw*_r functions and therefore that they should behave in the same
way.  But that would not be a problem for the reasons given above.

Mark