Array: Wrong work with VARCHAR elements [CORE1588]

[firebird-issue-importer]

Submitted by: @ibprovider

Votes: 1

All know servers (FB / IB) incorrect work with VARCHAR arrays - they always do not use first two bytes with length of string.

The problem exists in sdl.cpp - static const UCHAR* sdl_desc(const UCHAR* ptr, DSC* desc):
blr_varying and blr_varying2 convert to incorrect dtype_cstring

-------- [code from FB2.1 sources]
case blr_varying2:
desc->dsc_dtype = dtype_cstring;
INTL_ASSIGN_TTYPE(desc, get_word(sdl));
desc->dsc_length = sizeof(USHORT);
break;

case blr\_varying:
	desc\-\>dsc\_dtype = dtype\_cstring;
	INTL\_ASSIGN\_TTYPE\(desc, ttype\_dynamic\);
	desc\-\>dsc\_length = sizeof\(USHORT\);
	desc\-\>dsc\_flags \|= DSC\_no\_subtype;
	break;

--------

I think, correction of this bug will be include
- new ODS
- some changes in gbak

Connection component can detect the new ODS and use true algorithms for VARCHAR arrays.

For old ODS - current cstring-algorithm

[firebird-issue-importer]

Modified by: @pcisar

Workflow: jira [ 13403 ] => Firebird [ 14035 ]

[firebird-issue-importer]

Modified by: @ibprovider

Version: 2.5 RC2 [ 10372 ]

[firebird-issue-importer]

Commented by: @AlexPeshkoff

Hmm, I do not see how is it related with ODS. On disk varchars are stored in vary format: 2 bytes length, after it string itself. It's sdl descriptor (tmp object) which contains dtype_cstring instead dtype_varying. Before touching this legacy code I wonder - what real problem does it cause to you, and certainly a kind of test to reproduce is highly desired.

[firebird-issue-importer]

Commented by: @ibprovider

I offer append to new version of protocol (FB4?) the two new API functions - xxxx_put_slice2 and xxxx_get_slice2 with correct processing of VARYING arrays.

[firebird-issue-importer]

Commented by: @ibprovider

I offer the fix this mistake in FB4 without any look to backward compatibility.