;
; This file is automatically maintained by srccommit, do not edit manually.
;
GBLS Module_MajorVersion
GBLA Module_Version
GBLS Module_MinorVersion
GBLS Module_Date
GBLS Module_FullVersion
GBLS Module_ApplicationDate
GBLS Module_HelpVersion
GBLS Module_ComponentName
Module_MajorVersion SETS "6.70"
Module_Version SETA 670
Module_MinorVersion SETS ""
Module_Date SETS "20 Nov 2023"
Module_ApplicationDate SETS "20-Nov-23"
Module_ComponentName SETS "Kernel"
Module_FullVersion SETS "6.70"
Module_HelpVersion SETS "6.70 (20 Nov 2023)"
END-
Jeffrey Lee authored
The poor documentation of OS_Exit in the PRMs means there could be many pieces of software which are using it in a dangerous way. E.g. the famous issue of "OS_Exit generates a garbage error if the return code is out of range" that's documented in the OS StrongHelp manuals - where people (quite rightly) assumed that the OS would generate the "return code out of range" error, when in reality the OS has only ever used the error pointer that was supplied by the caller. Try and improve on things slightly by having OS_Exit sanity check the supplied error pointer before it tries to use it. This doesn't alter the cases where OS_Exit decides to silently ignore the supplied error pointer / return code (if R0 isn't word aligned, or historically, if R0 wasn't word aligned and wasn't in the low 64MB of address space), it just alters the logic for what error pointer gets sent to OS_GenerateError when it does decide to raise an error. If the error pointer looks bad (it's below &4000 or not pointing to at least 8 bytes of readable memory) then it will get swapped out for one of the "return code out of range" errors which get used when you *Set Sys$ReturnCode. Version 6.70. Tagged as 'Kernel-6_70'
2054b8fe