GitLab

Detail:
  The kernel has a 'callback postponement flag' which will be set whenever an X SWI, called from user mode, returns a pointer to an error (and the error block looks like it's in RAM).
  Although this flag will help prevent the error buffer from being overwritten by any errors generated by callbacks, it will also have the effect of blocking Alt-Break and CLib's Escape handler, due to them both being reliant on callbacks.
  Since the flag may persist for a long time, it can be dangerous to leave the OS in this state (the flag can only be cleared by a SWI call from user mode - which may never happen if the program is stuck in a bad state).
  So to combat this, CLib will now make some effort to try and avoid leaving the postponement flag in situations where it shouldn't be needed.
  File changes:
  - c/armsys:
    - Change _sys_flen to return 0 for TTY streams, since calling OS_Args for them isn't going to generate any useful result (previously it was generating an error, causing the postponement flag to be left set on entry to main())
    - Be extra vigilant when entering main() to make sure the callback postponement flag isn't set, just in case other checks don't resolve it
  - kernel/s/k_body:
    - Change CopyError to attempt to clear the callback postponement flag if we suspect it's set. We've just copied the error to our own buffer, so it should be our job to worry about preventing that buffer being prematurely overwritten, not the kernel's.
Admin:
  Tested on BB-xM
  'while (1) {}' (and similar variants) now multitasks in task windows and is no longer unkillable
  Fixes issue reported on forums:
  https://www.riscosopen.org/forum/forums/4/topics/11542#posts-79767


Version 5.96. Tagged as 'RISC_OSLib-5_96'