06.01.2022 04:28, Adriano dos Santos Fernandes wrote:
There is ExprNode::FLAG_VALUE ("Full value area required in impure
space"), inherited from old (2.5) code base nod_value.
It's set by sort subsystem and used only for parameters and variables.
Initially it as also used for fields. But at some point of time fields's
impure area became always sizeof(impure_value_ex), unconditionally.
It makes then allocate impure space for impure_value_ex instead of
traditional dsc.
I'd say allocating sizeof(dsc) is dangerous for these nodes. Look at
EVL_assign_to(), for example. It does:
impure_value* impure =
(impure_value*) ((SCHAR *) request + node->nod_impure);
...
impure->vlu_desc.dsc_dtype = desc->dsc_dtype;
...
return &impure->vlu_desc;
i.e. it works just because impure_value has "dsc vlu_desc" at the first
position and thus the used part of impure_value is equal to sizeof(dsc).
Change that and the things get broken. Try to use vlu_flags for
arguments/variables (make them invariant, for example) and things get
broken. Too fragile, IMO. I'd consider allocating sizeof(impure_value)
instead of sizeof(dsc), just for safety sake.
Most nodes allocate space for impure_value. But not all of them.
Literals directly return the descriptor set in compile time.
I see no usage of the expressions impure_value in sort. And if they were
using, we'd certainly have a problem with literals.
See also:
https://github.com/FirebirdSQL/firebird/issues/1355
https://github.com/FirebirdSQL/firebird/commit/626ab18c426fd32d482e02093e72e57330596174
Worth testing GROUP BY <literal>, <field> ?
Dmitry
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
