From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,8d52d4fbf051d828 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.224.182.74 with SMTP id cb10mr11928658qab.0.1346751632264; Tue, 04 Sep 2012 02:40:32 -0700 (PDT) Received: by 10.52.99.8 with SMTP id em8mr2230158vdb.16.1346751632240; Tue, 04 Sep 2012 02:40:32 -0700 (PDT) Path: da15ni7637554qab.0!nntp.google.com!b19no604555qas.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 4 Sep 2012 02:40:32 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=86.143.131.20; posting-account=04rmagoAAABZ9PN7u3MdbKIs6DPG57E- NNTP-Posting-Host: 86.143.131.20 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <474c2d57-9ac8-42f0-afd1-b32e4d8118b5@googlegroups.com> Subject: Re: Status of GNADE ODBC under Debian 64-bit From: Graham Stark Cc: mailbox@dmitry-kazakov.de Injection-Date: Tue, 04 Sep 2012 09:40:32 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-09-04T02:40:32-07:00 List-Id: I'm interested in this as I use GNADE quite a bit.=20 If you just change SQLUINTEGER to SQLUBIGINT in the indicated places Ludovi= c's warning goes away. It seems harmless either way, to the limited extent that= I understand the code - the thing that's declared as a pointer is really j= ust a bitmap, so it's just that the top 32 bits can't be set by that functi= on. The SQLLEN thing looks like a different problem and really quite nasty - I = hadn't come across this before. My reading of it is that some ODBC drivers = might need 32 bits there even on 64 bit systems; see this, for instance: ht= tp://www.martin-evans.me.uk/node/99 I have notice some funny behaviour retrieving strings from databases, where= the length is not returned correctly, so maybe that's the cause. Never see= n a crash, though. Graham