Re: namespace conflict for des
Simon Josefsson <[EMAIL PROTECTED]> writes: > The interface seem somewhat inefficient, because you can't do a > "setkey" operation and then use the scheduled key for several > operations. It has a strange license: > > * Sun RPC is a product of Sun Microsystems, Inc. and is provided for > * unrestricted use provided that I think that license is OK; it's compatible with the LGPL. > Unless someone feel strongly (and, preferably, even want to do the leg > work...) I'll simply fix the namespace of the current DES module. That sounds good. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: namespace conflict for des
Simon Josefsson <[EMAIL PROTECTED]> writes: > Oh. There is a POSIX "setkey" function. It is not thread safe, so I > can't use it. But GNU has setkey_r and encrypt_r in crypt.h. I think > gnulib should duplicate that API instead. I changed my mind -- that API uses as input 64 byte long strings, where each char is either "0" or "1". I.e., it uses an ASCII-encoding of each block. That is definitely not something we should promote. However, I discovered that glibc has another DES implementation: ecb_crypt and cbc_crypt in rpc/des_crypt.h. The interface seem somewhat inefficient, because you can't do a "setkey" operation and then use the scheduled key for several operations. It has a strange license: * Sun RPC is a product of Sun Microsystems, Inc. and is provided for * unrestricted use provided that this legend is included on all tape * media and as a part of the software program in whole or part. Users * may copy or modify Sun RPC without charge, but are not authorized * to license or distribute it to anyone else except as part of a product or * program developed by the user. However, detecting and replacing that code seem like real work, and I'm not sure we want to promote an RPC API either. Unless someone feel strongly (and, preferably, even want to do the leg work...) I'll simply fix the namespace of the current DES module. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: namespace conflict for des
Paul Eggert <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> I get this on freebsd 4.11: >> >> In file included from smbutil.c:34: >> lib/des.h:62: conflicting types for `des_setkey' >> /usr/include/unistd.h:128: previous declaration of `des_setkey' >> *** Error code 1 >> >> Should I rename the des_* functions to gl_des_* or is there some >> cleaner approach? > > Are the functions intended to have the same semantics? I dunno. If I type 'man des_setkey' on that system, I get a man page for libcrypt. 'des_setkey' isn't mention on the page. However, considering the prototype in unistd.h: int des_setkey __P((const char *key)); I would suspect the function somehow sets a global DES key schedule struct somewhere. Oh. There is a POSIX "setkey" function. It is not thread safe, so I can't use it. But GNU has setkey_r and encrypt_r in crypt.h. I think gnulib should duplicate that API instead. There may even be some opportunity to share code with glibc here. We would save code size on glibc systems, at least. Nice. I'll work on this... Thanks, Simon ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: namespace conflict for des
Hello, On Sun, Oct 23, 2005 at 10:25:48PM -0700, Paul Eggert wrote: > Simon Josefsson <[EMAIL PROTECTED]> writes: > > In file included from smbutil.c:34: > > lib/des.h:62: conflicting types for `des_setkey' ... > If they are supposed to have the same semantics but the FreeBSD > versions are buggy, you could rename the functions in unistd.h > instead, by using #define before #include . It's a bit of a > hack, as it requires that client code to include your .h file before > it includes unistd.h. I suppose another possibility is to use linker > magic but this is a bit less portable in practice. wouldn't it be better if lib/des.h contained #include #define des_setkey rpl_des_setkey What am I missing? Have a nice day, Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: namespace conflict for des
Simon Josefsson <[EMAIL PROTECTED]> writes: > I get this on freebsd 4.11: > > In file included from smbutil.c:34: > lib/des.h:62: conflicting types for `des_setkey' > /usr/include/unistd.h:128: previous declaration of `des_setkey' > *** Error code 1 > > Should I rename the des_* functions to gl_des_* or is there some > cleaner approach? Are the functions intended to have the same semantics? If so, perhaps you should arrange to use the FreeBSD versions while on FreeBSD. If not, perhaps the gnulib versions should be renamed. If they are supposed to have the same semantics but the FreeBSD versions are buggy, you could rename the functions in unistd.h instead, by using #define before #include . It's a bit of a hack, as it requires that client code to include your .h file before it includes unistd.h. I suppose another possibility is to use linker magic but this is a bit less portable in practice. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
namespace conflict for des
I get this on freebsd 4.11: In file included from smbutil.c:34: lib/des.h:62: conflicting types for `des_setkey' /usr/include/unistd.h:128: previous declaration of `des_setkey' *** Error code 1 Should I rename the des_* functions to gl_des_* or is there some cleaner approach? ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
