Hello, Paul!

Paul Reeves wrote:

> all. The problem has arisen because no check was made on expression
> size. It was possible to crash the server because of this. There is now
> a check and string expressions that evaluate to greater than 32k fail.
>
> I'm not sure how this one is going to be resolved. String expressions
> have to max out somewhere and 32k seems reasonable to me. The real
> problem is that no check was ever made in the past, so more than a few
> people have unknowingly taken advantage of this.

Here can be only one check - do not overflow 32K calculating string expressions.
And, when expression result (!) will be assigned to some variable,
check this variable DECLARATION to fit expression result.
Simple and working logic. I have not heard ever about checking
declared size of string variables in expression, and can't understand
it's purpose.
Examples:

s=c1||c2

s must fit concatenation of c1 and c2. If we have c1 and c2 as char(x),
of course, meaning data size we can use declared size, since char(x) always
padded with spaces.
If we have c1 and c2 as varchar(x), we must check concatenation not to overflow
size of s.
If expression evaluation in IB/FB can't know size of variable (field) being
assigned, it must think about 32767, max char types size, and check
overflow only at assignment point.

Another example:

select c1||c2 from table

c1, c2 = char(x). Here we must sum their declared lenght, and if it's bigger than
32767 (or bigger than y in cast(c1||c2 as var/char(y) or UDF(y)).
c1, c2 = varchar(x). Here we must sum their DATA. This will be resulting varchar
column length.

And yet another example:

using same charmax table I send as an example in FD, we can test
select rtrim(c) from charmax

It's OK!!! No errors. And what size of result will be?
Here is c = varchar(32765). rtrim have input and output strings declared
as cstring(80). Why error does not occur and must it ever occur?

I'm 100% sure that declared length must be checked only for char(x), as
I noted before. Right now, as I understand, char and varchar is being checked
for it's declaration, which IMHO is wrong.

> The real
> > problem is that no check was ever made in the past, so more than a few
> > people have unknowingly taken advantage of this.

I double citate your thought that a "few people" used this. Believe me,
not a few. A LOT OF. At least many UDFs have params as cstring(32767)
to enable processing of any sized strings. Using such declarations
in string expression completely disabled in V 1.0. People can't
move to v 1.0, they need to check their database, recompile a lot
of declarations, maybe creating 2 or more declarations of the
same functions for different cases (rtrim1, rtrim2 etc).
Is it normal? Is that are developer's expectations?

--
Dmitry Kuzmenko, Epsylon Technologies.