ibase_param_info() / ibase_field_info() prints garbage with table names, field names > 31 chars

[mlazdans]

Apparently XSQLVAR sqlname_length, relname_length, aliasname_length can be > 31 so using in such way is not safe, because corresponding buffer capacity is still 32 bytes:

php-firebird/ibase_query.c

Line 2109 in ce45760

add_index_stringl(return_value, 0, var->sqlname, var->sqlname_length);

Currently I got garbage printed but that's a potential segfault.

Buffer are still null terminated.

[mlazdans]

@AlexPeshkoff is this defined behaviour in Firebird or some sort of bug? I'm getting XSQLVAR array using isc_dsql_describe().

Connect using fbclient5 to FB5 database and do SELECT from a table with long field F{repeat 63x}:

Now connect using fbclient3 to same FB5 database:

All the corresponding names are NULL terminated at least but Unicode sequences are not respected.

Table itself has <smiley>x63 as name hence 252 bytes. DB is created with UTF8 and connected with UTF8.

[AlexPeshkoff]

On 10/28/25 00:23, mlazdans wrote: *mlazdans* left a comment (FirebirdSQL/php-firebird#87) <#87 (comment)> @AlexPeshkoff <https://github.com/AlexPeshkoff> is this defined behaviour in Firebird or some sort of bug? I'm getting XSQLVAR array using isc_dsql_describe(). Connect using fbclient5 to FB5 database and do |SELECT| from a table with long field |F{repeat 63x}|: image.png (view on web) <https://github.com/user-attachments/assets/877a0c8b-9ee5-4478-ab40-1dea8881f40b> Now connect using fbclient3 to same FB5 database: image.png (view on web) <https://github.com/user-attachments/assets/cdd36f8b-284d-4b8e-85a2-9a0b0cd50f90> All the corresponding names are NULL terminated at least but Unicode sequences are not respected. Table itself has |<smiley>x63| as name hence 252 bytes. DB is created with UTF8 and connected with UTF8.

Martin, I'm afraid that it is very hard to answer your question. I've certainly reproduced all mentioned issues locally, approximately this way: # ./isql -user sysdba -pas masterkey localhost:/tmp/xx -z ISQL Version: LI-V2.5.9.27183 Firebird 2.5 HQbird Server version: LI-V5.0.2.1613-dev Firebird 5.0 LI-V5.0.2.1613-dev Firebird 5.0/tcp (fbs3)/P15:C LI-V3.0.13.33813-dev Firebird 3.0/tcp (fbs3)/P15:C Database:  localhost:/tmp/xx, User: sysdba No entry for terminal type "xterm-256color"; using dumb terminal settings. SQL> set sqlda_display on; SQL> select * from "ДлинноеДлинноеРусскоеНазваниеИЕщёДлинней"; INPUT  SQLDA version: 1 sqln: 10 sqld: 0 OUTPUT SQLDA version: 1 sqln: 20 sqld: 1 01: sqltype: 496 LONG sqlscale: 0 sqlsubtype: 0 sqllen: 4  :  name: (63)                                FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF  alias: (63)                                FFFFFFFFFFFFFFFFFFFFFF FFFFFFFFF  : table: (80)                                                 ДлинноеДлинноеР�  owner: (6)SYSDBA                                FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ===============================================================                                                            137 On the one hand internally there are no buffer overflows, text is null terminated, i.e. formally (specially for fb5client) it looks OK. But on the other - that all is certainly as a minimum not friendly. It's rather easy to explain why UTF8 is truncated by client incorrectly - for a long time we do our best to avoid (specially for windows) need in ICU on client. I do not know why it's a "criminal" for windows but our windows guys state it surely. Lengths of names in fb3client is the worse thing here, they overflow buffer size in XSQLDA. Certainly this behavior can be easily fixed in next FB3 release, but I'm not sure will that release take place or not, quite possible that 3.0.13 is last in this branch. What about broken utf8 sequences The best way to deal with long utf names in database is to use MessageMetadata instead SQLDA. Even with fb3 (which has no long names support itself) talking to fb5 everything is OK: # ./isql -user sysdba -pas masterkey localhost:/tmp/xx -z ISQL Version: LI-V3.0.13.33813-dev Firebird 3.0 Server version: LI-V5.0.2.1613-dev Firebird 5.0 LI-V5.0.2.1613-dev Firebird 5.0/tcp (fbs3)/P15:C LI-V3.0.13.33813-dev Firebird 3.0/tcp (fbs3)/P15:C Database: localhost:/tmp/xx, User: SYSDBA SQL> set sqlda_display on; SQL> select * from "ДлинноеДлинноеРусскоеНазваниеИЕщёДлинней"; INPUT message field count: 0 OUTPUT message field count: 1 01: sqltype: 496 LONG scale: 0 subtype: 0 len: 4  :  name: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF  alias: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF F  : table: ДлинноеДлинноеРусскоеНазваниеИЕщёДлинней  owner: SYSDBA FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ===============================================================                                                            137 Alex.

[mlazdans]

MessageMetadata works correctly, yes. I use it now when client supports fb_get_statement_interface() - which is FB_API >= 40). We could use MessageMetadata from fbclient3 also but that require statement to be created via att->prepare() chain which I'm not sure I have time and willingness to rewrite now. Not sure - maybe I'm missing something but currently I'm getting IStatement using fb_get_statement_interface() and stmt handle from isc_dsql_allocate_statement().

For older clients I will just cap lengths with MIN(31, var->sqlname_length) or strlen(var->sqlname).

[mlazdans]

I'm not that much concerned with truncated / invalidated UTF8 sequences. More with the fact that these sqlname_length, etc fields from XSQLVAR has been and still might be used to get string lengths w/o checking. Possibly breaking old applications.

Btw do you really need ICU to detect UTF8 truncation? I believe I saw some very simple and nice solution / function somewhere. Will check it in spare time.

[mlazdans]

@AlexPeshkoff I saw you backported some changes into fb3 client. I did not do tests with your changes though and not sure if this is fixed (have not configured build env for firebird yet). Another strange thing. Same situation - fbclient 3 connects to fbserver 5 to database with long names but now on Windows. Now I get -1 in all length fields in XSQLVAR.

Compile-time Client Library Version => Firebird API version 50
Run-time Client Library Version => WI-V6.3.10.33601 Firebird 3.0
Server: WI-V5.0.2.1613 Firebird 5.0