Re: [libdbi-devel] libdbi endian problem

[Mike A. <mt...@um...>]

--On May 22, 2009 10:17:47 PM +0200 Markus Hoenicka 
<mar...@mh...> wrote:

> Mike Alexander writes:
>  > I've attached a patch to fix this.  This patch makes the code
> bigger,   > but not much slower.  If this is a problem it could be
> made conditional   > on the endianess of the target machine, but this
> didn't seem worth the   > trouble to me.
>
> Thanks Mike. I've applied the patch and tested it without any problems
> on FreeBSD. Unfortunately I can't test things on a PowerPC box myself,
> as "make check" in libdbi-drivers should have revealed this problem
> long ago. I didn't make the code conditional as it doesn't seem to
> cause much speed loss on low-endian machines, if at all.

Thanks.  Unfortunately I noticed a couple of issues with this patch. 
One of the data types supported by the union is DBI_INTEGER_SIZE3 but 
the union doesn't have a 3 byte integer field.  My change yesterday 
treated it as if it were a 2 byte field, but looking closer I see that 
the rest of the code treats it as if it were a 4 byte field.  I've 
attached a new patch that fixes this.  All that's needed is moving 2 
"case DBI_INTEGER_SIZE3" statements one or two lines later.

The other thing I noticed is that the Oracle driver still has an endian 
problem.  It lies about the type in the dbi_data_t struct that it 
returns.  It stores a long long value for all DBI_INTEGER_SIZE* types. 
This won't work on a big endian machine (after my changes).  See the 
code around line 640 in dbd_oracle.c to see what I'm talking about. 
Since I don't have Oracle or documentation for its API, this is not 
something I'm prepared to fix.

-- 
Mike Alexander           mt...@um...
Ann Arbor, MI            PGP key ID: BEA343A6