On Fri, Jun 09, 2006 at 10:07:44AM +0200, Daniel Stenberg wrote:
> On Fri, 9 Jun 2006, William Ahern wrote:
>
> >This patch is completely wrong. Bit-wise operations in C are on _logical_
> >values. Therefore, the previous DNS__16BIT and DNS__32BIT code was just
> >fine (the shifts are logically correct). Endianness would matter if you
> >tried to read or write directly from an integer type cast to a character
> >array, at which point you'd be going behind the compiler's back.
>
> Can you please post a patch that corrects this flaw?
>
This is against snapshot c-ares-1.3.1-20060609
--- ares_dns.h.orig Fri Jun 9 00:41:13 2006
+++ ares_dns.h Fri Jun 9 01:33:31 2006
@@ -18,18 +18,6 @@
#ifndef ARES__DNS_H
#define ARES__DNS_H
-#ifdef ARES_BIG_ENDIAN
-/* big-endian aware versions */
-#define DNS__16BIT(p) (((p)[1] << 8) | (p)[0])
-#define DNS__32BIT(p) (((p)[3] << 24) | ((p)[2] << 16) | \
- ((p)[1] << 8) | (p)[0])
-#define DNS__SET16BIT(p, v) (((p)[1] = ((v) >> 8) & 0xff), \
- ((p)[0] = (v) & 0xff))
-#define DNS__SET32BIT(p, v) (((p)[3] = ((v) >> 24) & 0xff), \
- ((p)[2] = ((v) >> 16) & 0xff), \
- ((p)[1] = ((v) >> 8) & 0xff), \
- ((p)[0] = (v) & 0xff))
-#else
#define DNS__16BIT(p) (((p)[0] << 8) | (p)[1])
#define DNS__32BIT(p) (((p)[0] << 24) | ((p)[1] << 16) | \
((p)[2] << 8) | (p)[3])
@@ -39,7 +27,6 @@
((p)[1] = ((v) >> 16) & 0xff), \
((p)[2] = ((v) >> 8) & 0xff), \
((p)[3] = (v) & 0xff))
-#endif
#if 0
/* we cannot use this approach on systems where we can't access 16/32 bit
Received on Fri Jun 9 10:35:58 2006