I wanted to share a small yet significant improvement I have made to the GCBASIC compiler. I have addressed an issue with the creation and use of constants with a leading zero.
Here is what was happening:
myVar = 01 // was being evaluated as 0... that is not right!
Previously, when you defined a constant with a leading zero, the compiler evaluated it as zero, which was clearly incorrect and led to unexpected results.
Solution:
I have made a small but effective change to the compiler. Now, when the compiler examines constants, if the constant starts with a single 0 and does not start with 0x (indicating a hexadecimal value), it will remove the leading zero.
This change ensures that:
myVar = 01 // will now be correctly evaluated as 1
Risks of the Change:
While this improvement is beneficial, there are some potential risks to consider:
Unintended Behaviour for Legacy Code:
If existing code relies on the previous behaviour (where 01 was evaluated as 0), this change might break such code. Developers who were aware of the old behaviour and worked around it may now encounter unexpected results.
Edge Cases:
There may be edge cases I have not accounted for, particularly if there are other numeric formats that need specific handling. Ensuring that all potential formats are correctly parsed is crucial to avoid further bugs.
User Confusion:
Users who are not aware of the change might get confused if their code suddenly behaves differently. Clear communication and documentation about the change are essential to mitigate this risk.
This post mitigates this risk.
Compatibility Issues:
If the compiler is used in environments or with tools that expect the old behaviour, there might be compatibility issues. Ensuring thorough testing in all supported environments is necessary.
Testing Overhead:
Adequate testing must be conducted to ensure that the change does not introduce new bugs. This includes unit tests, integration tests, and regression tests to verify that the new behaviour is correct and does not negatively impact other parts of the compiler.
I have completed all the static tests and I have seen no impact.
Despite these risks, I believe that the benefits of the change far outweigh the potential downsides.
This tweak has been implemented in build 1460 and seems to work perfectly, addressing the issue and ensuring more accurate evaluations of your constants.
Evan
❤️
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
See https://ko-fi.com/post/An-Update-for-GCBASIC-Compiler-Users-Small-Change-I2I319E76P
I wanted to share a small yet significant improvement I have made to the GCBASIC compiler. I have addressed an issue with the creation and use of constants with a leading zero.
Here is what was happening:
Previously, when you defined a constant with a leading zero, the compiler evaluated it as zero, which was clearly incorrect and led to unexpected results.
Solution:
I have made a small but effective change to the compiler. Now, when the compiler examines constants, if the constant starts with a single 0 and does not start with 0x (indicating a hexadecimal value), it will remove the leading zero.
This change ensures that:
Risks of the Change:
While this improvement is beneficial, there are some potential risks to consider:
Unintended Behaviour for Legacy Code:
If existing code relies on the previous behaviour (where
01was evaluated as0), this change might break such code. Developers who were aware of the old behaviour and worked around it may now encounter unexpected results.Edge Cases:
There may be edge cases I have not accounted for, particularly if there are other numeric formats that need specific handling. Ensuring that all potential formats are correctly parsed is crucial to avoid further bugs.
User Confusion:
Users who are not aware of the change might get confused if their code suddenly behaves differently. Clear communication and documentation about the change are essential to mitigate this risk.
This post mitigates this risk.
Compatibility Issues:
If the compiler is used in environments or with tools that expect the old behaviour, there might be compatibility issues. Ensuring thorough testing in all supported environments is necessary.
Testing Overhead:
Adequate testing must be conducted to ensure that the change does not introduce new bugs. This includes unit tests, integration tests, and regression tests to verify that the new behaviour is correct and does not negatively impact other parts of the compiler.
I have completed all the static tests and I have seen no impact.
Despite these risks, I believe that the benefits of the change far outweigh the potential downsides.
This tweak has been implemented in build 1460 and seems to work perfectly, addressing the issue and ensuring more accurate evaluations of your constants.
Evan
very nice:-)
i agree the feeleing of fixing some small things is incredible
and every you type var= aleays come to mind :&)