|
From: Claudio V. C. <cv...@us...> - 2007-02-04 09:03:55
|
Hello, all.
As you know, there's no standardized way to put a 64-bit value as parameter
in the printf family. This is the reason common.h defines QUADFORMAT as
platform dependent. Examples:
"ll"
"q"
"I64"
Indeed, the 64-bit indicator is a modifier to the %d or %u argument. I
anticipate that we'll need to pass more big values as parameters for
messages. Gbak already demands that and we simply coerce the value to SLONG
before passing it to BURP_verbose. When I spoke to Jim a year ago about this
issue, he said he solved it by using varargs routines. Wrong. The problem is
the data type in the messages database, not finding a more flexible way to
pass the arguments that will fill the message' parameters. The biggest value
we handle is %d and maybe in a 64-bit architecture and operating system, %d
will mean the native integer type (a 64-bit quantity) but not in the 32-bit
architectures and I doubt the latter will disappear next year.
The problem is that messages are independent of the architecture. You can't
use the QUADFORMAT macro we use inside the server. For example, msg 85 in
the gbak facility is
"restoring generator %s value: %ld"
and we'll try a simple case:
F:\fb2dev\fbbuild\firebird2\temp\debug\firebird\bin>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> create database 'genval.fdb';
SQL> create generator high;
SQL> set generator high to 1024 * 1024 * 1024 * 1024;
Statement failed, SQLCODE = -104
Dynamic SQL Error
-SQL error code = -104
-Token unknown - line 1, column 28
-*
Ok, I tried to outsmart it but SET GENERATOR won't handle expressions.
:-)
SQL> select 1024 * 1024 * 1024 * 1024 from rdb$database;
MULTIPLY
=====================
1099511627776
SQL> set generator high to 1099511627776;
SQL> ^Z
Now I'm going to backup and restore with verbosity. Pay attention to the
generator message:
F:\fb2dev\fbbuild\firebird2\temp\debug\firebird\bin>gbak -b genval.fdb
genval.fbk -v
...
gbak:writing id generators
gbak: writing generator HIGH value 0
Hey, my generator wasn't zero. I found a bug!
(No, the message screws the value when forcing INT64 to SLONG.)
...
gbak:closing file, committing, and finishing. 1536 bytes written
F:\fb2dev\fbbuild\firebird2\temp\debug\firebird\bin>gbak -rep genval.fbk
genval.fdb -v
...
Again, the same issue:
gbak:restoring generator HIGH value: 0
...
gbak:finishing, closing, and going home
F:\fb2dev\fbbuild\firebird2\temp\debug\firebird\bin>isql genval.fdb
Database: genval.fdb
SQL> show generator high;
Generator HIGH, current value is 1099511627776
SQL> ^Z
The message scared the user, but the data was correct inside the backup.
One cumbersome solution is to convert the 64-bit value to string. When you
see the "closing file, committing and finishing. N bytes written" message at
the end of backup, the bytes count is done this way.
Another way is to make the messages in the msg db understand a generic type
to mean 64 bit values. Remember, the messages in the db are platform
neutral. For example, we scan for %v64 and replace it at run-time by the
correct indicator (SQUADFORMAT macro in our case) for the given platform.
Do you see better, simpler, cleverer solution? For me, misrepresenting the
values as it happens now it's not an option.
C.
---
Claudio Valderrama C.
SW developer, consultant.
http://www.cvalde.net - http://www.firebirdsql.org
|