Unexpected error "arithmetic exception, numeric overflow, or string truncation" while evaluating SUBSTRING the second time [CORE2300]

[firebird-automations]

Submitted by: @dyemanov

Is related to QA384

Test case:

create procedure p
returns ( res varchar(10) )
as begin
res = null;
suspend;
res = '0123456789';
suspend;
end

commit;

select substring(res from 1 for 5) from p order by 1; -- success
select substring(res from 1 for 5) from p order by 1; -- error

Arithmetic overflow or division by zero has occurred.
arithmetic exception, numeric overflow, or string truncation.
string right truncation.

The problem seems to be caused by the fact that the DSC_null flag is analyzed at both prepare-time and runtime but descriptors can be persistent and thus keep the runtime value until the next time.

In this particular case, the first select call sets DSC_null for the procedure's output and the second select call checks this flag during prepare and describes the output as VARCHAR(1) instead of VARCHAR(10), then this short length is used to prepare the sort buffer and at runtime string truncation happens, because a CHAR(10) string cannot be assigned to a CHAR(1) buffer.

Commits: 0b2322d

[firebird-automations]

Modified by: @dyemanov

assignee: Adriano dos Santos Fernandes [ asfernandes ]

[firebird-automations]

Commented by: @asfernandes

I had to comment a line present since v1.5. It was setting DSC_null on the shared procedure format.

I tested with TCS and it didn't fail.

[firebird-automations]

Modified by: @asfernandes

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5 Beta 1 [ 10251 ]

[firebird-automations]

Commented by: @hvlad

The fix is correct, you may remove that commented line ;)

I think proc_assignment() declaration must be changed by

static void proc_assignment(thread_db*, const dsc* const, const dsc* const, UCHAR*, const dsc* const, SSHORT, Record*);

i.e. use "const dsc* const" instead of "const dsc*" to explicitly disable change of descriptors.

[firebird-automations]

Commented by: @asfernandes

Thanks for review.

About the const, I never understand the need for such usage. Not because I don't understand how it apply, but because I don't understand its benefit used in "some" places.

I mean, if we think the const apply in this place, there is no difference in think it apply for all the others parameters too:
static void proc_assignment(thread_db* const, const dsc* const, const dsc* const, UCHAR* const, const dsc* const, SSHORT const, Record* const);

It compiles ok, and has the same meaning of don't allow a local variable to change. And then we're adding consts to every variable.

[firebird-automations]

Modified by: @pcisar

Link: This issue is related to QA384 [ QA384 ]

[firebird-automations]

Commented by: @pcisar

QA test added.

[firebird-automations]

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

[firebird-automations]

Modified by: @pavel-zotov

QA Status: No test

[firebird-automations]

Modified by: @pavel-zotov

QA Status: No test => Done successfully