INVSVN error for any invalid special variable names a leading substring of which matches the valid prefix of a valid intrinsic special variable

[shabiel]

Final Release Note

Description

Once an abbreviation for an ISV is satisfied, YottaDB ignores the rest of the ISV, even if it is invalid. For example:

YDB>w $zre
698448
YDB>w $zrealstor 
698448
YDB>w $zreference
698448
YDB>w $zrex     
698448
YDB>

Draft Release Note

YottaDB raises an INVSVN error when it encounters an invalid intrinsic special variable name a leading substring of which matches the minimum leading substring of a valid intrinsic special variable name (e.g., $ZREX is an invalid special variable name, whose leading substring $ZRE is the valid abbreviation of the valid intrinsic special variable $ZREALSTOR). Previously, YottaDB accepted such invalid special variable names as valid substiutes for the correct intrinsic special variable.

[ksbhaskar]

Sam, in your original report, were you looking for $reference?

[shabiel]

It wasn't me who was looking for it; but yes, that was the intent.

--Sam

On Thu, May 10, 2018 at 10:59 AM, K.S. Bhaskar notifications@github.com wrote:

Sam, in your original report, were you looking for $reference https://docs.yottadb.com/ProgrammersGuide/isv.html#reference?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/YottaDB/YottaDB/issues/243#issuecomment-388080046, or mute the thread https://github.com/notifications/unsubscribe-auth/ABEtwp3Ny59yM2QIQ1OooiQhZg3SY4aXks5txFXkgaJpZM4T580Z .

[shabiel]

Christopher came over this weekend and we discussed in detail what's behind this error. I told him the story of how it got into Fileman

He asked me for the version of GTM/YDB that correctly crashed on $ZREFERENCE (which is how we discovered the issue): It's GTM:

GT.M V6.3-004 Linux x86_64

--Sam

On Thu, May 10, 2018 at 11:10 AM, Sam Habiel sam.habiel@gmail.com wrote:

It wasn't me who was looking for it; but yes, that was the intent.

--Sam

On Thu, May 10, 2018 at 10:59 AM, K.S. Bhaskar notifications@github.com wrote:

Sam, in your original report, were you looking for $reference https://docs.yottadb.com/ProgrammersGuide/isv.html#reference?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/YottaDB/YottaDB/issues/243#issuecomment-388080046, or mute the thread https://github.com/notifications/unsubscribe-auth/ABEtwp3Ny59yM2QIQ1OooiQhZg3SY4aXks5txFXkgaJpZM4T580Z .

[shabiel]

http://tinco.pair.com/bhaskar/gtm/doc/articles/GTM_V6.3-004_Release_Notes.html

Forgot to say: I checked the release notes; and there doesn't seem to be an item that says that ISV parsing got changed.

On Mon, May 14, 2018 at 10:56 AM, Sam Habiel sam.habiel@gmail.com wrote:

Christopher came over this weekend and we discussed in detail what's behind this error. I told him the story of how it got into Fileman

He asked me for the version of GTM/YDB that correctly crashed on $ZREFERENCE (which is how we discovered the issue): It's GTM:

GT.M V6.3-004 Linux x86_64

--Sam

On Thu, May 10, 2018 at 11:10 AM, Sam Habiel sam.habiel@gmail.com wrote:

It wasn't me who was looking for it; but yes, that was the intent.

--Sam

On Thu, May 10, 2018 at 10:59 AM, K.S. Bhaskar notifications@github.com wrote:

Sam, in your original report, were you looking for $reference https://docs.yottadb.com/ProgrammersGuide/isv.html#reference?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/YottaDB/YottaDB/issues/243#issuecomment-388080046, or mute the thread https://github.com/notifications/unsubscribe-auth/ABEtwp3Ny59yM2QIQ1OooiQhZg3SY4aXks5txFXkgaJpZM4T580Z .

[nars1]

This comment is not suggesting a fix but explaining the problem. The ISV parsing logic did not change but a new ISV was added which shares a prefix with $ZREFERENCE. Until GT.M V6.3-003, $ZRE was being treated as $ZREALSTOR. So $ZREFERENCE was being treated as $ZREALSTOR and so worked silently (even though using an unintended ISV). In V6.3-004, a new ISV $ZRELDATE was introduced so now $ZRE or $ZREA are being treated as $ZREALSTOR and $ZREL being treated as $ZRELDATE. And $ZREFERENCE does not fall in either $ZREA or $ZREL* and hence comes out as an invalid ISV.

[shabiel]

I see. That makes sense now. So... basically, there may be no bug at this point.

On Mon, May 14, 2018 at 12:07 PM, Narayanan Iyer notifications@github.com wrote:

This comment is not suggesting a fix but explaining the problem. The ISV parsing logic did not change but a new ISV was added which shares a prefix with $ZREFERENCE. Until GT.M V6.3-004, $ZRE was being treated as $ZREALSTOR. So $ZREFERENCE was being treated as $ZREALSTOR and so worked silently (even though using an unintended ISV). In V6.3-004, a new ISV $ZRELDATE was introduced so now $ZRE or $ZREA are being treated as $ZREALSTOR and $ZREL being treated as $ZRELDATE. And $ZREFERENCE does not fall in either $ZREA or $ZREL* and hence comes out as an invalid ISV.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/YottaDB/YottaDB/issues/243#issuecomment-388872196, or mute the thread https://github.com/notifications/unsubscribe-auth/ABEtwkdacG43Id-m0gWHOTA6zfHi0vOxks5tyavAgaJpZM4T580Z .

[nars1]

@shabiel, @ksbhaskar : I think that (i.e. this is not a bug but a feature) is the easiest way to resolve this in my opinion. Changing the ISV handling logic to issue an error like this issue title suggests might have other/subtle backward compatibility implications.

[ksbhaskar]

Note that this is flagged as a won't fix.

[nars1]

In that case, can this issue be closed. Having an open "won't fix" issue does not make sense to me.