Dilwyn Jones wrote: > INPUT #channel,t$ should fetch a string from a file. Indeed it does > unless the buffer is not large enough for the size of string. QLib's > default input buffer is 128 bytes like a JM or AH rom and can be > enlarged with a $$buff command on post-JM systems. Trouble is, if the > string is longer than the buffer it ought to give a 'buffer full' > error message which could be trapped with a Q_ERR_ON 'input' > statement, instead the compiled program just locks up.
Okay, I have analyzed this. The INPUT hangs in an endless loop, trying to resize the buffer, forever doomed to fail. Problem with the code is, I don't quite understand the intentions behind the way the INPUT command was written and at the most important line the command doesn't match the comment next to it! Is the command right and the comment wrong? Or the other way round? Who knows. Though I have a hunch that the code is right. Anyway, I can fix it by ensuring that only interpreted Basic tries to enlarge the buffer, returning the error for compiled programs. By the way, I did also analyze how Minerva will behave. It will simply kill your compiled job! So while SMSQ/E can be changed to return "buffer overflow", you'll need to use a command other than INPUT for it to work on other platforms. > Works fine interpreted, you would expect it to cause a 'buffer > overflow' error message when QLiberator compiled due to exceeding the > input buffer length (which could be error trapped) but on my system > the compiled program locks up with no error message. Sometimes with > (not so) pretty screen pattern corruption. In SMSQ/E? Marcel _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
