Re: base64.? going into rfc3548bis
Simon Josefsson [EMAIL PROTECTED] writes: Alternatively, the prototype could be 'void*' for the data and cast it to 'uint8_t*' internally. That would be safe, wouldn't it? No, because C implementations need not support uint8_t. It is an optional type. Come to think of it, even 'char *' might have problems, since the value (char) 0x80 might be a 'trap representation', which causes undefined behavior if you try to use it. So you may need to change the interface to use 'unsigned char *' instead. The C Standard says that 'unsigned char' is safe; it cannot possibly have a trap representation. But all this is relevant only if you want the code to be portable to hosts where CHAR_BIT is not 8, or which do not use two's complement. For sanity's sake, you may be better on insisting that CHAR_BIT is 8, and on using unsigned char so that UCHAR_MAX must be 255. That's good enough for an RFC, I think. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
FYI: argp.h/argz.h and error_t
* Ralf Wildenhues wrote on Mon, Mar 20, 2006 at 08:36:26AM CET: [ this is http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/5424 ] Sorry for the delay, here's a patch. Cc:ing libtool-patches as the owner of the argz module. If you agree, I'll check this into Libtool as well. I have applied this patch to both Libtool HEAD and gnulib. Thanks for the access BTW. Cheers, Ralf * argz.m4 (gl_FUNC_ARGZ): If we define `error_t', also define `__error_t_defined', so argp.h will not typedef the former. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: base64.? going into rfc3548bis
Paul Eggert [EMAIL PROTECTED] writes: Ralf Wildenhues [EMAIL PROTECTED] writes: - *out++ = b64str[to_uchar (in[0]) 2]; + *out++ = b64str[(to_uchar (in[0]) 2) 0x3f]; This change doesn't feel right to me. It is ignoring the fact that the input to base64_encode is invalid. The input is invalid because base64_encode is supposed to encode a series of octets, and you are working around the problem that the input is not a series of octets. You could change the interface so that base64_encode returns a boolean, indicating encoding failure. Alternatively, the prototype could be 'void*' for the data and cast it to 'uint8_t*' internally. That would be safe, wouldn't it? This (that is, using 'void*') may even be cleaner, because sometimes you want to encode non-char binary data. On the other hand, you may then have endian and padding issues depending on how you are trying to use it, but within the same software, encoding and decoding opaque objects using base64 seem possible. Another possibility, which probably makes more sense, is to simply say that CHAR_BIT must be 8. In reference code, you can check this as follows: #if CHAR_BIT != 8 #error This code assumes that CHAR_BIT is 8. #endif POSIX already assumes CHAR_BIT is 8, so you're on pretty safe grounds nowadays if you assume it. It's not worth going to a lot of effort worrying about non-8-bit hosts. I'm sure there are other bugs in base64.c in this area, and we don't have time to scan for them. After a quick review, I think the code handle CHAR_BIT 8 fine except for this problem. But I'm inclined to follow your suggestion anyway, if we can't agree on the void/uint8_t idea above. Thanks. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: PATCH to stdint_.h for OpenBSD Sparc64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark D. Baushke [EMAIL PROTECTED] writes:
Hi Folks,
For this is the bug report:
http://savannah.nongnu.org/bugs/?func=detailitemitem_id=15040
CVS needs the following patch applied to GNULIB/lib/stdlib_.h
FYI. I have applied this patch to the CVS sources
(:ext:cvs.savannah.nongnu.org/cvsroot/cvs).
-- Mark
Apparently, OpenBSD puts the standard exact-width integer types into
/usr/include/machine/int_types.h which is included by both sys/types.h
and stddef.h.
Alex has verified that the patch below fixes his problem building CVS on
his OpenBSD box.
Thanks,
-- Mark
2006-03-26 Mark D. Baushke [EMAIL PROTECTED]
* stdint_.h: Protect against OpenBSD integer types from
sys/types.h.
Index: stdint_.h
===
RCS file: /cvsroot/cvs/ccvs/lib/stdint_.h,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 stdint_.h
--- stdint_.h 25 Jan 2006 12:53:38 - 1.5
+++ stdint_.h 27 Mar 2006 02:20:56 -
@@ -33,6 +33,9 @@
#if defined(__FreeBSD__)
# include sys/inttypes.h
#endif
+#if defined(__OpenBSD__)
+# include sys/types.h
+#endif
#if defined(__linux__) HAVE_SYS_BITYPES_H
/* Linux libc4 = 4.6.7 and libc5 have a sys/bitypes.h that defines
int{8,16,32,64}_t and __BIT_TYPES_DEFINED__. In libc5 = 5.2.2 it is
@@ -62,7 +65,7 @@
/* 7.18.1.1. Exact-width integer types */
-#if !defined(__FreeBSD__)
+#if !defined(__FreeBSD__) !defined(__OpenBSD__)
#ifdef _STDINT_H_NEED_SIGNED_INT_TYPES
typedef signed charint8_t;
@@ -97,7 +100,7 @@ typedef unsigned __int64 uint64_t;
#define _STDINT_H_HAVE_INT64
#endif
-#endif /* !FreeBSD */
+#endif /* !FreeBSD !OpenBSD */
/* 7.18.1.2. Minimum-width integer types */
@@ -127,14 +130,14 @@ typedef uint64_t uint_fast64_t;
/* 7.18.1.4. Integer types capable of holding object pointers */
-#if !defined(__FreeBSD__)
+#if !defined(__FreeBSD__) !defined(__OpenBSD__)
/* On some platforms (like IRIX6 MIPS with -n32) sizeof(void*)
sizeof(long),
but this doesn't matter here. */
typedef long intptr_t;
typedef unsigned long uintptr_t;
-#endif /* !FreeBSD */
+#endif /* !FreeBSD !OpenBSD */
/* 7.18.1.5. Greatest-width integer types */
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (FreeBSD)
iD8DBQFEKGZMCg7APGsDnFERArS0AKC1E6pbPiaPPfILQyw69KFdK5EA7QCghHBe
Q3ZOMKVzNoV1R3r+/c/fUyQ=
=04xO
-END PGP SIGNATURE-
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
