From owner-freebsd-hackers Wed Sep 24 11:05:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA14850 for hackers-outgoing; Wed, 24 Sep 1997 11:05:43 -0700 (PDT) Received: from roguetrader.com (brandon@cold.org [206.81.134.103]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA14828 for ; Wed, 24 Sep 1997 11:05:35 -0700 (PDT) Received: from localhost (brandon@localhost) by roguetrader.com (8.8.5/8.8.5) with SMTP id MAA06117 for ; Wed, 24 Sep 1997 12:06:29 -0600 (MDT) Date: Wed, 24 Sep 1997 12:06:29 -0600 (MDT) From: Brandon Gillespie To: freebsd-hackers@freebsd.org Subject: crypt() returning an error... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The man page on crypt() states that a NULL will be returned instead of a pointer to a string, if an error occurred. The MD5 crypt does not follow this, however DES crypt does. Furthermore, in the attempt to hunt out a 'standard' for handling error codes, I have checked how other crypt() implementations function. OpenBSD for some unknown reason returns the string: ":" Where Digital Unix also returns a NULL, as does Unixware--however their manual pages do not specify NULL as a valid return value. With this in mind, I think I will standardize this behaviour to 'crypt()' in that if an error occurs (there are more possibilities, with the additional $x$x$x.. possibilities) then a NULL will be returned. This means that what currently works with MD5 crypt will no longer be the case. For instance: crypt("", "") With MD5 will actually return an encrypted value, with a zero-length salt. After my changes, this will return a NULL instead. Anybody forsee any problems with this? I do not, but I figured I would bring it up...