Re: [Firebird-docs] isc_expand_dpb

[Ann W. H. <aha...@ib...>]

Andy,


    May I suggest putting this on the architecture
list or the firebird development list?  Or maybe
not after you've read my comments?

>What's wrong with isc_expand_dpb() -
>
>[1] There is a difference between the size of a buffer and the size of the 
>data in the buffer....

That's an error in the example - the caller should supply the length of the
buffer, not the length of the data.

>[2] The API says that isc_expand_dpb() allocates a new buffer if it needs 
>it. However, there is nothing said about what happens to the old buffer. 
>There is no deallocation of the old buffer.

The comments in the code say that the original intended user
for this (gpre) generates code to release the allocated buffer.
Gpre also generates exactly one call to isc_expand_dpb, so there
are no intermediate allocations to get lost.

FYI, dpb stands for database parameter block.


>...    isc_fill_dpb( & dpb, & dpb_length, isc_dpb_user_name, username );
>...    isc_free_dpb( dbp );


without adding two more calls to the (bloated) interface, you
could just allocated and stuff the block yourself.  It's simple.
one byte of dpb version, the identifier, a byte of length, then
the value, and continue with identifier, length, value triplets
until done.  Keep track of the length and if your next value
will overflow, allocate a bigger block, copy the data, & release
the old block.

>* When we wish to, we can cause isc_attach_database to store the 
>dpb_length in an unsigned long integer, and recognize the isc_dpb_length 
>code, updating the (small) number it received from the caller with the 
>(large) number it finds in the dbp itself. When we do this we will no 
>longer be limited to 32767 bytes in the dbp.

That limit has not yet been a problem.

>I am a little concerned that the length of a string in the dbp buffer is 
>limited to 255 characters by the use of one byte as a length byte; file 
>names under Windows 98 are limited to 32,767 bytes.

Again, that limit hasn't been a problem up to now - very few people actually
use names longer than 200 characters because of the improbability of typing
them right.

>If the user calls isc_fill_dpb() to put the strings into the dbp, we can 
>set the format code to "2" and make the upgrade invisible to the caller.

I don't see this as worth the overall cost.

>Of course we need to keep isc_expand_dpb() in the API to support old code; 
>however we should discourage it's use.

I'd just stop there.


>I welcome any comments. According to the API, isc_expand_dpb() and 
>isc_attach_database() are the only two functions that use the dbp at all. 
>But there is a TPB - maybe we should make the code handle both? How does 
>this fix fit in with plans that others have?

The tpb (transaction parameter block) works like the dpb, and like
creating the dbp, creating a tpb is within the skill set of any
dull-normal programmer.


Regards,

Ann
www.ibphoenix.com
We have answers.