Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of bojan@rexursive.com
 designates 203.171.74.242 as permitted sender)
Subject: Re: Warnings for apr_dbd_odbc.c on 64-bit platforms
From: Bojan Smojver <bojan@rexursive.com>
To: Tom.Donovan@acm.org
Cc: APR Developer List <dev@apr.apache.org>
In-Reply-To: <48586CBC.7080509@bellatlantic.net>
References: <1213747952.6007.10.camel@shrek.rexursive.com>
	 <48586CBC.7080509@bellatlantic.net>
Content-Type: text/plain
Date: Wed, 18 Jun 2008 12:24:18 +1000
Message-Id: <1213755858.6007.27.camel@shrek.rexursive.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Tue, 2008-06-17 at 22:02 -0400, Tom Donovan wrote:
>  
> The Microsoft ODBC docs at http://msdn.microsoft.com/en-us/library/ms713605(VS.85).aspx say:
> 
>    SQLPOINTER      ValuePtr
>    [Input] Pointer to the value to be associated with Attribute. Depending on the value of
>    Attribute, ValuePtr will be a 32-bit unsigned integer value or will point to a null-terminated
>    character string. Note that if the Attribute argument is a driver-specific value, the value in
>    ValuePtr may be a signed integer.
> 
> The DB2 CLI/ODBC docs say the same - 
> http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/ad/r0000646.htm
> 
> UnixODBC & iODBC usually treat the MS ODBC docs as authoritative, so it seems likely that this is as 
> intended.  I don't have a 64-bit system to give it a try on.
> 
> hmmm...   ODBC really shows its age here!

Yeah, it does. SQLPOINTER on Linux is defined as void *, so it will be a
64-bit value on 64-bit systems, contrary to the above 32-bit assumption.
This kind of pointer/integer mixing is really a bad idea, but there is
nothing we can do about it, I guess.

Thanks for the input.

-- 
Bojan