Re: [bug-gnulib] verify.h in C++? Boost has me worried.
Bruno Haible [EMAIL PROTECTED] writes: You really tortured your students with this beast?! :-) Well, not the whole thing. The current verify.h doesn't work with C++ - error types may not be defined in 'sizeof' expressions. Find appended a fix, tested with g++ 3.2.2 and 4.0.1. Thanks, I installed that. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
getaddrinfo.h: HAVE_SYS_TYPES_H needed?
Hi Simon, I noticed that getaddrinfo.h guards the inclusion of sys/types.h with an #ifdef HAVE_SYS_TYPES_H. Do you know of a system that lacks sys/types.h? I don't see any other uses of HAVE_SYS_TYPES_H in gnulib. How about HAVE_SYS_SOCKET_H? At least poll.c uses sys/socket.h without the conditional. It's best to avoid the conditionals, when possible. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: getaddrinfo.h: HAVE_SYS_TYPES_H needed?
Jim Meyering [EMAIL PROTECTED] writes: Hi Simon, I noticed that getaddrinfo.h guards the inclusion of sys/types.h with an #ifdef HAVE_SYS_TYPES_H. Do you know of a system that lacks sys/types.h? Hi Jim! No, I don't. I don't see any other uses of HAVE_SYS_TYPES_H in gnulib. I removed the check. How about HAVE_SYS_SOCKET_H? At least poll.c uses sys/socket.h without the conditional. It's best to avoid the conditionals, when possible. Mingw32 doesn't have sys/socket.h, but gnulib doesn't support it anyway, so I removed the check. The proper fix on mingw32 would be to supply, in a gnulib module, some working sys/socket.h files. What about netdb.h then? Is there any system that lack it? I'm leaving the tests in getaddrinfo.m4 for a while, so that more debug information end up in config.log. Thanks, Simon ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
memxor
Hi. This is a helper module needed by the hmac-md5 crypto module that
I'll post after this. What do you think? Ok to install?
I am not sure about the prototype. Should it use 'char*'? 'int*'?
The implementation XOR the data buffers char by char, but there is no
inherent requirement that it is done that way, so I thought the API
should use 'void*' similar to memcpy.
Thanks.
Index: m4/memxor.m4
===
RCS file: m4/memxor.m4
diff -N m4/memxor.m4
--- /dev/null 1 Jan 1970 00:00:00 -
+++ m4/memxor.m45 Oct 2005 12:07:36 -
@@ -0,0 +1,11 @@
+# memxor.m4 serial 1
+dnl Copyright (C) 2005 Free Software Foundation, Inc.
+dnl This file is free software; the Free Software Foundation
+dnl gives unlimited permission to copy and/or distribute it,
+dnl with or without modifications, as long as this notice is preserved.
+
+AC_DEFUN([gl_MEMXOR],
+[
+ AC_LIBSOURCES([memxor.h, memxor.c])
+ AC_LIBOBJ([memxor])
+])
Index: lib/memxor.h
===
RCS file: lib/memxor.h
diff -N lib/memxor.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/memxor.h5 Oct 2005 12:07:36 -
@@ -0,0 +1,28 @@
+/* memxor.h -- perform binary exclusive OR operation on memory blocks.
+ Copyright (C) 2005 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software Foundation,
+ Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */
+
+/* Written by Simon Josefsson. The interface was inspired by memxor
+ in Niels Möller's Nettle. */
+
+#ifndef MEMXOR_H
+# define MEMXOR_H
+
+#include stddef.h
+
+void *memxor (void *dest, const void *src, size_t n);
+
+#endif /* MEMXOR_H */
Index: lib/memxor.c
===
RCS file: lib/memxor.c
diff -N lib/memxor.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/memxor.c5 Oct 2005 12:07:36 -
@@ -0,0 +1,38 @@
+/* memxor.c -- perform binary exclusive OR operation of two memory blocks.
+ Copyright (C) 2005 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software Foundation,
+ Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */
+
+/* Written by Simon Josefsson. The interface was inspired by memxor
+ in Niels Möller's Nettle. */
+
+#ifdef HAVE_CONFIG_H
+# include config.h
+#endif
+
+#include memxor.h
+
+void *
+memxor (void *dest, const void *src, size_t n)
+{
+ const char *s = src;
+ char *d = dest;
+ size_t i;
+
+ for (i = 0; i n; i++)
+d[i] ^= s[i];
+
+ return dest;
+}
Index: modules/memxor
===
RCS file: modules/memxor
diff -N modules/memxor
--- /dev/null 1 Jan 1970 00:00:00 -
+++ modules/memxor 5 Oct 2005 12:07:36 -
@@ -0,0 +1,23 @@
+Description:
+memxor() function: binary exclusive or operation on two memory blocks
+
+Files:
+lib/memxor.h
+lib/memxor.c
+m4/memxor.m4
+
+Depends-on:
+
+configure.ac:
+gl_MEMXOR
+
+Makefile.am:
+
+Include:
+memxor.h
+
+License:
+LGPL
+
+Maintainer:
+Simon Josefsson
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: hmac-md5
Bruno Haible [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
This is the HMAC-MD5 module, that depends on the MD5 module.
What do you think? Ok to install?
The reason I'm using hmac.h instead of hmac-md5.h is that I think
hmac.h should contain the prototype for hmac_sha1 too, eventually.
That would be a separate module with a hmac-sha1.c implementation,
though, but it would share the hmac.h header.
This module is welcome. I like to see an interface that is easier to use
than md5.h.
Yes, I found md5.h a bit cumbersome too. Note that HMAC-MD5 is not
the same as MD5, I may be reading you incorrectly but I get the
impression that you think hmac-md5.c is a simpler interface for md5.c;
it is not. Hmac-md5 implement the algorithm in RFC 2104, which do use
md5, but is very different in what it is used for.
Regarding the different digest algorithms: It appears that most programs
which offer one of these algorithms also offer other algorithms. MD5, SHA-1,
etc. (md5sum/sha1sum, gpg --digest-algo, etc.) Therefore I would put
hmac-md5.c and hmac-sha1.c into the same gnulib module. And then a single
header file hmac.h will do.
Would work, but not if the sha1 stays under GPL. I need LGPL'd crypto
libraries. We can change this later, if I can re-license sha1 as
LGPL.
You can then also add a function that takes the digest algorithm as a
parameter:
enum { HMAC_MD5, HMAC_SHA1, HMAC_RIPEMD_128, HMAC_RIPEMD_160 };
Yes, this will come later, I'm submitting the functions as needed
one-by-one now.
I am unsure about the prototype here too. I'm using 'void*', but I
considered using 'uint8_t*' because HMAC-MD5 is byte-oriented.
I would prefer 'uint8_t*', because the contents of the memory block is
not completely opaque: The result of md5 depends on the encoding of
the values. If, for example, every byte is XORed with 0x77, the result
will be different. Unlike, for example, memcmp, memcpy, hash_insert, ...
For 'uint8_t', you can use the gnulib module 'stdint'. Or use 'unsigned char'
if you don't want to.
The problem with uint8_t is that sooner or later it ends up in public
API's, and while I'm using ax_create_stdint_h.m4 in my projects,
something like it is not yet part of gnulib.
One problem with 'char*' (and 'unsigned char*') is that it isn't
guaranteed to be 8 bytes. So it could be larger, e.g., 16 bytes. I
have no idea whether the code will work at all in that case.
Further, using uint8_t in hmac-md5 and 'void*' and 'char*' in md5
(yes, it uses both) seem rather inconsistent. Is it likely that we'll
be able to change the glibc API to use uint8_t?
It would be nice if the md5 module contained a '#define MD5_BLOCK_SIZE
64' and '#define MD5_DIGEST_SIZE 16' so I don't have to hard code
those numbers. Should I submit a patch?
Yes, I think this would be useful in glibc's source code too.
I fixed this in gnulib (not synchronized to glibc cvs ), and
submitted http://sourceware.org/bugzilla/show_bug.cgi?id=1423.
Note that there are no hooks for using libgcrypt instead. That will
came later on. First I need the crypto functionality inside gnulib,
then I can write a layer on top of that to multiplex the functionality
to either the gnulib modules or to libgcrypt.
Yes, this seems like the right approach.
Yes, that code is running locally here now. Will submit later...
Thanks,
Simon
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: hmac-md5
Bruno Haible [EMAIL PROTECTED] writes: For 'uint8_t', you can use the gnulib module 'stdint'. Or use 'unsigned char' if you don't want to. I just noticed that the 'stdint' module was GPL. Would it be possible to re-license it? Otherwise I'll just 'unsigned char*' or 'void*' for hmac-md5. Given the potential problems with multi-byte char's, I'm leaning towards void* right now, unless someone can re-assure me that 'unsigned char*' work portably. Has anyone used md5_buffer from the md5 module on a platform with char that is larger than 1 byte? Does it work? Looking at the code, I suspect some potential endianness problem, since it uses 'memcpy' to move 'char*' buffers around. Thanks, Simon ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: stdint license
Simon Josefsson wrote: I just noticed that the 'stdint' module was GPL. Would it be possible to re-license it? Yes, done (assuming Oskar's agreement). Bruno ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
FYI: getdelim.c needs SIZE_MAX
Paul's recent change to getdelim.c breaks the build on at least NetBSD 1.6.1: 2005-10-03 Paul Eggert [EMAIL PROTECTED] * getdelim.c: Include getdelim.h first. Include limits.h. (SSIZE_MAX): New macro, if not already defined. (getdelim): Fix buffer overrun on 64-bit hosts with lines longer than 2 GiB. The problem is that the new SSIZE_MAX macro depends on SIZE_MAX, which may not be defined. I've installed the attached patch, ripped verbatim from serveral other modules. 2005-10-05 Derek Price [EMAIL PROTECTED] * getdelim.c (SIZE_MAX): New macro, if not already defined. Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot http://ximbiot.com v: +1 717.579.6168 f: +1 717.234.3125 mailto:[EMAIL PROTECTED] Index: lib/getdelim.c === RCS file: /cvsroot/gnulib/gnulib/lib/getdelim.c,v retrieving revision 1.5 diff -u -p -r1.5 getdelim.c --- lib/getdelim.c 3 Oct 2005 19:44:05 - 1.5 +++ lib/getdelim.c 5 Oct 2005 18:05:05 - @@ -29,6 +29,9 @@ #include stdlib.h #include errno.h +#ifndef SIZE_MAX +# define SIZE_MAX ((size_t) -1) +#endif #ifndef SSIZE_MAX # define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2)) #endif ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: FYI: getdelim.c needs SIZE_MAX
Simon Josefsson wrote: Derek Price [EMAIL PROTECTED] writes: may not be defined. I've installed the attached patch, ripped verbatim from serveral other modules. Shouldn't we use the size_max module instead? I'm not sure. Some 18 modules currently don't, defining SIZE_MAX themselves. Do you know why not? I seem to recall a past discussion on this list that decided that replacing 3 lines of code wasn't worth the module dependancy, I thought in regards to this module, though I can't find the thread. I think the size_max module is only important if you want to use SIZE_MAX as part of a preprocessor conditional - otherwise this definition works fine. [EMAIL PROTECTED] gnulib]$ fgrep -w 'define SIZE_MAX' lib/*.[hc] lib/argp-help.c:# define SIZE_MAX ((size_t) -1) lib/backupfile.c:# define SIZE_MAX ((size_t) -1) lib/error.c:# define SIZE_MAX ((size_t) -1) lib/fnmatch.c:# define SIZE_MAX ((size_t) -1) lib/fts.c:# define SIZE_MAX ((size_t) -1) lib/getdelim.c:# define SIZE_MAX ((size_t) -1) lib/getndelim2.c:# define SIZE_MAX ((size_t) -1) lib/hash.c:# define SIZE_MAX ((size_t) -1) lib/human.c:# define SIZE_MAX ((size_t) -1) lib/iconvme.c:# define SIZE_MAX ((size_t) -1) lib/mountlist.c:# define SIZE_MAX ((size_t) -1) lib/quotearg.c:# define SIZE_MAX ((size_t) -1) lib/readutmp.c:# define SIZE_MAX ((size_t) -1) lib/regex_internal.h:# define SIZE_MAX ((size_t) -1) lib/stdint_.h:#define SIZE_MAX (~(size_t)0) lib/utimecmp.c:# define SIZE_MAX ((size_t) -1) lib/xmalloc.c:# define SIZE_MAX ((size_t) -1) lib/xreadlink.c:# define SIZE_MAX ((size_t) -1) [EMAIL PROTECTED] gnulib]$ Incidentally, the #define SIZE_MAX (~(size_t)0) in lib/stdint_.h may not be portable: http://lists.gnu.org/archive/html/bug-gnulib/2004-03/msg00022.html. Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot http://ximbiot.com v: +1 717.579.6168 f: +1 717.234.3125 mailto:[EMAIL PROTECTED] ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: getaddrinfo.h: HAVE_SYS_TYPES_H needed?
Simon Josefsson [EMAIL PROTECTED] writes: The tests for these headers in getaddrinfo.m4 should probably be removed eventually. No time like the present, right? I installed this: 2005-10-05 Paul Eggert [EMAIL PROTECTED] * getaddrinfo.m4 (gl_PREREQ_GETADDRINFO): Don't check for sys/socket.h, netdb.h, sys/types.h; the checks areno longer needed, since the source code now assumes these .h files. --- getaddrinfo.m4 1 Oct 2005 11:19:16 - 1.10 +++ getaddrinfo.m4 5 Oct 2005 21:41:31 - 1.12 @@ -1,4 +1,4 @@ -# getaddrinfo.m4 serial 6 +# getaddrinfo.m4 serial 7 dnl Copyright (C) 2004, 2005 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -19,30 +19,18 @@ AC_DEFUN([gl_PREREQ_GETADDRINFO], [ AC_REQUIRE([gl_SOCKET_FAMILIES]) AC_REQUIRE([AC_C_INLINE]) AC_REQUIRE([AC_GNU_SOURCE]) - AC_CHECK_HEADERS_ONCE(sys/socket.h netdb.h sys/types.h netinet/in.h) + AC_CHECK_HEADERS_ONCE(netinet/in.h) AC_CHECK_DECLS([getaddrinfo, freeaddrinfo, gai_strerror],,,[ /* sys/types.h is not needed according to POSIX, but the sys/socket.h in i386-unknown-freebsd4.10 and powerpc-apple-darwin5.5 required it. */ -#ifdef HAVE_SYS_TYPES_H -# include sys/types.h -#endif -#ifdef HAVE_SYS_SOCKET_H -# include sys/socket.h -#endif -#ifdef HAVE_NETDB_H -# include netdb.h -#endif +#include sys/types.h +#include sys/socket.h +#include netdb.h ]) AC_CHECK_TYPES([struct addrinfo],,,[ -#ifdef HAVE_SYS_TYPES_H -# include sys/types.h -#endif -#ifdef HAVE_SYS_SOCKET_H -# include sys/socket.h -#endif -#ifdef HAVE_NETDB_H -# include netdb.h -#endif +#include sys/types.h +#include sys/socket.h +#include netdb.h ]) ]) ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: memxor
Simon Josefsson [EMAIL PROTECTED] writes: I am not sure about the prototype. Should it use 'char*'? 'int*'? If its name is mem* then it should use void *, for consistency. The current implementation uses 'restrict', so memxor.m4 should AC_REQUIRE([gl_C_RESTRICT]) and the memxor module should depend on the restrict module. The current implementation casts 'const void *' to 'char *', which will provoke warnings with many compilers. Also, it contains unnecessary casts. How about this implementation instead? char *d = dest; char const *s = src; for (; n 0; n--) *d++ ^= *s++; return dest; ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: hmac-md5
Simon Josefsson [EMAIL PROTECTED] writes: Has anyone used md5_buffer from the md5 module on a platform with char that is larger than 1 byte? Do you mean a host where UCHAR_MAX 255? I doubt whether anyone has done that. POSIX requires that UCHAR_MAX == 255. A small fraction of GNU code is portable to hosts where UCHAR_MAX 255, but usually this is more for the amusement of the author than anything else. If you meant sizeof (char) 1, then I really doubt whether anyone has done that. C has required that sizeof (char) == 1 for ages. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
