Re: Undefined type LDAP_UINT4 (ITS#341)

[kurt@boolean.net]

At 01:22 PM 11/3/99 GMT, kst@SDSC.EDU wrote:
>> SHA1 code requires that uint32 to be EXACTLY 32 bits long.
>
>I'm working on a tentative solution.

The long term solution must be to rework or replace our SHA1
implementation such that it is not dependent on specific sizes
of integer types (and their byte order).

>In ldap/include/ac/bytes.h,
>I'm adding code that will use type {signed,unsigned,} short for
>LDAP_{S,U,}INT4 if short is 4 bytes (and both int and long are
>bigger than 4 bytes).  This covers the T3E.  If neither long, int,
>nor short is 4 bytes, it falls through to a "#error" directive; this
>means it won't compile on the Cray T90, but at least the reason for
>the failure will be clear.

Exactly.

>In ldap/include/lutil_md5.h, the comment states that uint32 should
>be defined as unsigned long, so I'll just leave it that way.
>In ldap/include/lutil_sha1.h, I'll define uint32 as LDAP_UINT4,
>which is now guaranteed to be exactly 4 bytes.
>
>I'm not comfortable about uint32 being defined differently in
>two different headers.  If both headers are included in the same
>compilation unit

Which they are....  liblutil/passwd.c

>, the first one included will get to define uint32
>(since the typedef is surrounded by #ifndef ... #endif); this would
>be A Bad Thing.  If there's no chance of this happening, it's merely
>poor style, IMHO.  For that matter, the name uint32 is commonly used
>in system headers; for example, see <rpc/rpc_sztypes.h> on Solaris.

Our use of uint32 is confined to specific internal codes.  To date,
there has been to conflict.

>I strongly suggest picking a name, or names, unique to LDAP.

We are moving in this direction for both published interfaces and
internal codes.   For MD5, we can replace all uses of uint32 with
an appropriate lber_type.h type (-devel only).  For the current
SHA1 code, we must have a 32-bit integer.  I'll look at using C99
types, but I believe the real solution new SHA1 code.

>Comments?
>
>Note that C99 defines a number of integer typedefs in the new
>header <stdint.h>.  The type uint32_t, which is guaranteed to be
>exactly 32 bits wide, would be suitable as a replacement for the
>uint32 in lutil_sha1.h.  The type uint_least32_t would be a good
>choice for the uint32 in lutil_md5.h.  Of course, few implementations
>provide this header, but Doug Gwyn has written public-domain versions
>of several C99 headers that will work with a C89 implementation.
>See <http://www.lysator.liu.se/c/q8/index.html>.

C99 is not widely available.  However, if available, I see no problem
with taking advantage of what it offers.

>> Also note, we, in general, prefer to apply changes to OpenLDAP-devel
>> first and then back port the changes to 1.2.
>
>At this point, my top priority is to get this working with Globus.

Well, then, I would just hack lutil_sha1.h to use any available
32 bit integer supported on the platform.  If none is available,
I'd #ifdef out all SHA1 support.

>Globus is currently using a patched version of OpenLDAP 1.2.7, available
>at <ftp://ftp.globus.org/pub/globus/OpenLDAP-1.2.7-globus.tar.gz>,
>so I need to work with the 1.2.7 sources for now.  Once that's stable,
>I'll port the changes to OpenLDAP-devel -- and hopefully there'll be
>no need for OpenLDAP-1.2.7-globus.


----
Kurt D. Zeilenga		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>