Re: simple problem with string handling

Odd that the RPG does not simply return the empty string for the result of the %subst opcode in that example, and therefore evaluate to false for the comparison. Any substring of a varying variable that has the value of the empty-string is always the empty-string, much like the product of any numeric with the zero-value is always zero. FWiW the SQL will return the empty-string in that case using its SUBSTR scalar function [and LEFT, RIGHT, ¿and others?].

Doubtful, but maybe if it were reported as a defect [often enough] instead of being accepted as the expected outcome, the RPG would actually change to do [what is IMO, and probably also for many others,] the correct thing, instead of giving an error.?

While the SQL also does not fail for substring beyond the declared maximum length of the varying field, nor even for a zero or negative start position or length [since some release change IIRC], I could see the RNX0100 remaining as the effect for those situations in the RPG for %subst. Similarly SQL will LOCATE an empty-string in an empty-string, but if %scan could not, that is not a big issue like the %subst being unable to deal /properly/ with the empty-string.

Regards, Chuck

On 25 Feb 2013 04:27, j.beckeringh wrote:

Although I'm strongly in favour of using varying length strings,
there is one thing that has bitten me a few times: substringing on
a position that is outside the size of the string;

For example:

if %subst(path :1 :1) = '/';
// absolute path
else;
// relative path
endif;

will bomb if path is an empty varying length field. <<SNIP>>