BBC BASIC
« Bug alert »

Welcome Guest. Please Login or Register.
Jan 23rd, 2018, 7:13pm


Cross-platform BBC BASIC (Win32, Linux x86, Android, Mac OS-X, Raspberry Pi)

« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 thread  Author  Topic: Bug alert  (Read 915 times)
Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 692
xx Bug alert
« Thread started on: Dec 22nd, 2016, 10:42am »

Unfortunately a bug has been discovered in BB4W (BBCSDL is affected too). You need not be too concerned because the bug only manifests in rare and obscure circumstances; indeed it cannot cause a problem if the recommended variable naming conventions are strictly adhered to. Nevertheless a user was unlucky enough to be affected by it.

The circumstances in which the bug can show itself are as follows:
  • A procedure (or function) takes a string parameter.

  • The 'actual' parameter is a user-defined function (FN) which returns a string value.

  • The 'formal' parameter is a string variable that is modified by the user-defined function.
Here is a code snippet which meets these conditions and would activate the bug:

Code:
      PROCbugdemo(FNactual)
      ...
      END

      DEF PROCbugdemo(formal$)
      ...
      ENDPROC

      DEF FNactual
      formal$ = "side effect"
      = "parameter" 

What happens is that part-way through the internal process of saving the formal parameter, and assigning to it the value of the actual parameter, the formal parameter 'unexpectedly' changes (because of the side-effect of the function). This confuses BB4W and leaves it in an unstable state.

If the naming conventions are followed, a 'global' variable changed by a user-defined function can't have the same name as a 'local' formal parameter, so the conditions for the bug will not be met. The Cross Reference Utility will warn you if they are.

I will attempt to fix this bug in the next releases of BB4W and BBCSDL but the change needed is in a crucial bit of code and I need to be careful that the 'cure' doesn't turn out to be worse than the 'illness'.

Richard.
« Last Edit: Dec 22nd, 2016, 4:49pm by Richard Russell » User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 692
xx Re: Bug alert
« Reply #1 on: Dec 22nd, 2016, 11:54pm »

on Dec 22nd, 2016, 10:42am, Richard Russell wrote:
I will attempt to fix this bug in the next releases of BB4W and BBCSDL

I've realised that I won't be able to "fix" it, as such - not least because it's not clear what the 'correct' behaviour should be in these circumstances. Specifically, referring to the code snippet, what value should be left in the 'formal$' variable on return from PROCbugdemo? Should it be what was originally in it when PROCbugdemo was called, or the string "side effect" written into it by FNactual?

There's no unambiguous 'right' or 'wrong' here, so instead what I will attempt to do is to raise an error (probably 'Incorrect arguments') if the situation arises. That way, at least, the user won't be left with BB4W in an unstable state that could cause problems 'downstream'. He will know that he must modify the program to avoid the problem entirely.

Richard.
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 692
xx Re: Bug alert
« Reply #2 on: Jan 1st, 2017, 09:34am »

on Dec 23rd, 2016, 6:52pm, Richard Russell wrote:
I do now have a work-in-progress version which issues the 'Incorrect arguments' error (code 31) if it detects the 'unstable' condition.  So rather than behaving in a confusing way that it almost impossible to diagnose, it will result in a 'hard failure' forcing the programmer to pay attention!

My inclination, in the interests of 'risk management', is to initially release a new version of BBCSDL with this modification, and only later consider updating BB4W. This will give people a chance to check it out in a product still in a development phase, and therefore not so critical in respect of any accidentally-introduced bugs.

No compatibility issues should arise from this modification, because it checks for a condition which is guaranteed to leave BBC BASIC in an unstable state. But it's possible that somebody has a program which suffers from this effect without ever having realised it (if so, they really need to know!).

If I stick to my usual quarterly schedule the next release of BBCSDL is due at the beginning of February, so I will tentatively plan to incorporate the new code then. Does anybody disagree with this plan?

Richard.
User IP Logged

RNBW
New Member
Image


member is offline

Avatar




PM

Gender: Male
Posts: 23
xx Re: Bug alert
« Reply #3 on: Jan 1st, 2017, 10:22am »

Happy New Year Richard and all BBC Basic users.

I think your suggestion is sensible.
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 692
xx Re: Bug alert
« Reply #4 on: Feb 19th, 2017, 11:12am »

on Jan 1st, 2017, 09:34am, Richard Russell wrote:
My inclination, in the interests of 'risk management', is to initially release a new version of BBCSDL with this modification

Can I remind everybody that the recently released BBCSDL v0.16 is this version and that therefore it needs to be hammered to ensure that the workaround I have added - i.e. to report an error if the condition that can result in instability arises - is effective, safe and has no unwanted side effects.

So please do as much testing of BBCSDL v0.16 as you possibly can. Particularly, test calling procedures (PROC) and functions (FN) in as many ways as you can think of, including passing a User Defined Function as a parameter. You might like to deliberately reproduce the conditions that activate the 'bug', so you can see that the behaviour has changed.

If you haven't yet downloaded and tried BBCSDL, because you thought that it wasn't relevant to you, now it is! The reliability of future releases of BB4W, which will incorporate the same workaround, is dependent on the degree of testing that BBCSDL v0.16 receives.

Richard.
« Last Edit: Feb 19th, 2017, 11:13am by Richard Russell » User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 692
xx Re: Bug alert
« Reply #5 on: Mar 26th, 2017, 09:30am »

on Feb 19th, 2017, 11:12am, Richard Russell wrote:
So please do as much testing of BBCSDL v0.16 as you possibly can. Particularly, test calling procedures (PROC) and functions (FN) in as many ways as you can think of, including passing a User Defined Function as a parameter.

I've not received any feedback, positive or negative, as yet.   I can only hope that this is because lots of people have been doing lots of testing, without any problems being identified, rather than that very few people have done very little testing!

I cannot emphasise too strongly how reliant I am, and hence how dependent the reliability of the next release of BB4W will be, on extensive third-party testing.  The nature of the modifications to workaround this bug/feature means that it is not appropriate for the programmer who made them to do the testing.  He (i.e. I) cannot be sufficiently objective, especially given the huge number of possible ways in which procedures and functions can be called in BBC BASIC.

So when the next version of BB4W is released it will be the diligence of your fellow users that you are relying on when it comes to having confidence in the product.

Richard.
User IP Logged

Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

Donate $6.99 for 50,000 Ad-Free Pageviews!


This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls