forth2012-test-suite icon indicating copy to clipboard operation
forth2012-test-suite copied to clipboard

Overlapping source/destination buffers in SUBSTITUTE tests

Open pahihu opened this issue 1 year ago • 2 comments

In stringtest.fth the following 2 tests use overlapping source and destination buffers and hence the tests fails:

T{ $" c%mac3%d" 0 3 do-subst show $" czyxwvutd" 1 check-subst -> TRUE }T T{ $" e%mac2%f" 0 3 do-subst show $" ezyxf" 1 check-subst -> TRUE }T

Thanks, pahihu

pahihu avatar Jan 06 '23 19:01 pahihu

Well yes, it is testing for overlapping strings, including the case for SUBSTITUTE ( c-addr1 u1 c-addr2 u2 -- c-addr2 u3 n ) where c-addr1 = caddr2 which is an error and an example of an overlapping string. See line 237 onwards in file stringtest.fth. When I first wrote the test I expected that systems would test for that and return a negative number to indicate an error.

However developers of one system ( I think it was GForth but I might be wrong) said that their system handled overlapping strings correctly and why should they be penalised for providing a better implementation. I thought they had a good point so I wrote the tests which handled various cases for overlapping strings in the tests in lines 299 to 304. The value n returned and substitution is expected to be correct if n >= 0, if a system returns n<0 then the tests pass without the resulting string being checked, see line 271 in the definition of CHECK-SUBST. It looks as if the system you're running the tests on returns n>=0 with an invalid resulting string.

In general standard systems can ignore errors so perhaps I should add some code to check for a system that ignores overlapping strings - I'll have to think about that. In the meantime please comment out the offending tests if failure is causing you a problem.

Thanks for reporting it. Gerry Jackson PS I replied to your email directly thinking it would get posted here automatically but it didn't, hence this is a few days late.

gerryjackson avatar Jan 13 '23 21:01 gerryjackson

Thank you for the explanation. I have used the reference implementation for SUBSTITUTE found on the Forth2012 standard website, so I was wondering that those tests failed.

Andras Pahi

On 2023. Jan 13., at 22:56, gerryjackson @.***> wrote:

Well yes, it is testing for overlapping strings, including the case for SUBSTITUTE ( c-addr1 u1 c-addr2 u2 -- c-addr2 u3 n ) where c-addr1 = caddr2 which is an error and an example of an overlapping string. See line 237 onwards in file stringtest.fth. When I first wrote the test I expected that systems would test for that and return a negative number to indicate an error.

However developers of one system ( I think it was GForth but I might be wrong) said that their system handled overlapping strings correctly and why should they be penalised for providing a better implementation. I thought they had a good point so I wrote the tests which handled various cases for overlapping strings in the tests in lines 299 to 304. The value n returned and substitution is expected to be correct if n >= 0, if a system returns n<0 then the tests pass without the resulting string being checked, see line 271 in the definition of CHECK-SUBST. It looks as if the system you're running the tests on returns n>=0 with an invalid resulting string.

In general standard systems can ignore errors so perhaps I should add some code to check for a system that ignores overlapping strings - I'll have to think about that. In the meantime please comment out the offending tests if failure is causing you a problem.

Thanks for reporting it. Gerry Jackson PS I replied to your email directly thinking it would get posted here automatically but it didn't, hence this is a few days late.

— Reply to this email directly, view it on GitHub https://github.com/gerryjackson/forth2012-test-suite/issues/38#issuecomment-1382436123, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADTEB2ZPVY5PIBCYXJFL2KTWSHFQ5ANCNFSM6AAAAAATTMSZKU. You are receiving this because you authored the thread.

pahihu avatar Jan 13 '23 22:01 pahihu