AMD64 and Qt 4.2.2 issue

[Gianni Rossi]

Hi,

I have just had a problem compiling Qt's (4.2.2) plugin for firebird
(2.0.0.12748).  At first I though the problem was with Qt, but investigating
the problem I found that it arose from these lines in ibase.h:

#if defined(_LP64) || defined(__LP64__) || defined(__arch64__)
typedef unsigned int    FB_API_HANDLE;
#else
typedef void*           FB_API_HANDLE;
#endif

In Qt's code, it has the following function:

QVariant QIBaseResult::handle() const
{
    return QVariant(qRegisterMetaType<isc_stmt_handle>("isc_stmt_handle"),
d->stmt);
}

which fails because it was expecting "d->stmt" to be a pointer.  To me, it
seems that changing isc_stmt_handle from a pointer to a 'simple' uint
depending on the architecture is a problem, this should be consistant.  I'm
not very fluent in C++, but it seems that the declaration should be:

#if defined(_LP64) || defined(__LP64__) || defined(__arch64__)
typedef unsigned int*    FB_API_HANDLE;
#else
typedef void*           FB_API_HANDLE;
#endif

??  Is this right or am I missing something here?


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Michal Kubecek]

On Sun, Dec 31, 2006 at 08:08:13PM -0200, Gianni Rossi wrote:
>
> which fails because it was expecting "d->stmt" to be a pointer.  To me, it
> seems that changing isc_stmt_handle from a pointer to a 'simple' uint
> depending on the architecture is a problem, this should be consistant.

I agree, it caused problems in Firebird code as well, some casts had to
be changed from C++ safe casts to traditional ones to compile with gcc4.
But I'm not sure it would be easy to change this because FB_API_HANDLE
is exported outside of Firebird.

>  I'm not very fluent in C++, but it seems that the declaration should
>  be:
>
> #if defined(_LP64) || defined(__LP64__) || defined(__arch64__)
> typedef unsigned int*    FB_API_HANDLE;
> #else
> typedef void*           FB_API_HANDLE;
> #endif
>
> ??  Is this right or am I missing something here?

This is surely not right. The reason for different definition is that
FB_API_HANDLE has to be 32-bit on all platforms. Therefore on 64-bit
platforms (with 64-bit pointers) it is defined as (32-bit) unsigned int.
For a consistent definition, uint32_t (or some unsigned 32-bit integer
type where stdint.h isn't available) should be used.

                                                          Michal Kubecek


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Claudio Valderrama C.]

> -----Original Message-----
> From: firebird-devel-bounces@...
> [mailto:firebird-devel-bounces@...]On Behalf Of Michal
> Kubecek
> Sent: Lunes, 01 de Enero de 2007 10:10
>
> This is surely not right. The reason for different definition is that
> FB_API_HANDLE has to be 32-bit on all platforms. Therefore on 64-bit
> platforms (with 64-bit pointers) it is defined as (32-bit) unsigned int.
> For a consistent definition, uint32_t (or some unsigned 32-bit integer
> type where stdint.h isn't available) should be used.

Yes, it would be better to stick to integers always so we don't have this
mess with different types of casts.

C.



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Ann W. Harrison]

Claudio Valderrama C. wrote:

>>
>> This is surely not right. The reason for different definition is that
>> FB_API_HANDLE has to be 32-bit on all platforms. Therefore on 64-bit
>> platforms (with 64-bit pointers) it is defined as (32-bit) unsigned int.
>> For a consistent definition, uint32_t (or some unsigned 32-bit integer
>> type where stdint.h isn't available) should be used.
>
> Yes, it would be better to stick to integers always so we don't have this
> mess with different types of casts.
>

Integer isn't well defined, so sticking to int32 might be a better
choice.  In ancient history, the Cray architecture had a 64 bit
char, 64 bit short, and 64 bit integer.


Regards,


Ann

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Steve Friedl]

Hi folks,

How much interest is there in an SNMP agent for monitoring Firebird
1.5.x lock statistics?

I've been using Firebird as an admin for >5 years supporting a line-of-biz
application using 1.5.x Classic Server as a database backend, and I
think we're getting killed with lock contention. Buying faster and faster
hardware doesn't contribute that much to better performance, which causes
no small amount of chagrin to the small companies using this software.

My discovery of fb_lock_print and Ann's wonderful paper on the same has
been a real eye opener, but there is only so much I can do from a tuning
point of view: at some point I have to involve the vendor.

Loving the fb_lock_print data but wanting to see it over time and correlated
with other system performance data, I created a Firebird MIB that loads into
Net-SNMP's snmpd and reports on a coupla dozen parameters. Though the code is
still kinda rough, it's graphing reliably on several systems right now with
the Cacti monitoring system.

An annotated sample showing mutex waits -vs- CPU & context switch time:

        http://www.unixwiz.net/misc/fbperf.gif

(this was researching some pathological behavior).

I'm new enough to Firebird development (and this list) that I don't know
how well this might "fit" here. I think it probably works with Classic
or Super Server, but probably not with 2.0.

I don't know if 1.5.x is so old that nobody cares any more -- I just
know that *our* app requires it.

Happy New Year.

Steve

--
Stephen J Friedl | Security Consultant |  UNIX Wizard  |   [phone]
www.unixwiz.net  | Tustin, Calif. USA  | Microsoft MVP | steve@...

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel