SWI &2B returned a bad error pointer

Andrew suggested

[the book] probably should now come with an addendum to say that the code contained therein is no longer correct!

The book is correct. The author wrote

numbers with bit 30 set (beginning with &40000000) are available for use within programs.

And the PRMs say

[b30] can therefore be used by programmers to flag internal errors.

Both of which have said that for a very long time. I am sorry there has been some recent confusion, but that’s been remedied now.

Bit 30 is defined to be clear, and can therefore be used by programmers to flag internal errors.

I interpret that as “this should be zero but doesn’t have to be”. Either way, one shouldn’t assume that this bit will be zero.
[of course, the rigidity of the word “should” comes into play here just as much as the scope of what “internal” means]

and b29 – “should be cleared for compatibility with any future extensions”.

…which is then immediately followed by information on how ADFS uses those bits if bit 31 is also set… :-)

Lesson to be learned? Don’t assume what the bits mean, just keep calm and report the error…

The book is correct.

That part of the book is correct, but the example code which then chucks the internal error out into the world is (apparently) not.

Rick pointed out

which is then immediately followed by information on how ADFS uses those bits if bit 31 is also set… :-)

Yes, b31 trumps everything, it redefines the whole of the rest. Then, if it is clear, b30. Then the error-range interpretation. In other words:

• Is b31 set? It’s a fatal error, fatal error ranges apply
• else, is b30 set? It’s an internal application error, keep your nose out
• else, error ranges in b8-23

Lesson to be learned? Don’t assume what the bits mean, just keep calm and report the error…

Well, more precisely, the application flagging the error is sending it to its error handler, so the application and the error handler know what the error means if b30 is set. ErrorV claimants and Service_Error listeners however, should pay attention to b31 and b30 if they are going to do any interpretation of ranges.

In my experience, the very few error ‘listeners’ (as opposed to the official error handler) either log everything or look for a very specific error number.

@nemo

I can see that you are absolutely certain in your position but if the other interpretation is correct your example can be done like this.

DIM err% 256
ONERRORPROCerr
ERROR&40000001,"Woggle"

DEFPROCerr
!err% = ERR
$err% = REPORT$ + CHR$(0)
IF ERR AND(1<<30): !err% = AN_ALLOCATED_NUMBER: $err% = A$="Internal error: "+REPORT$ +CHR$(0)
SYS"Wimp_ReportError", err%
IFERRAND(1<<30):END
ENDPROC

That way internally you can distinguish between errors internally but externally report with an allocated number. As if as you point out an internal error number has no meaning outside your program it doesn’t matter that all internal errors are reported with the same number.

You gave me a good explanation of how my interpretation of ‘internal’ that it doesn’t mean internal to the organisation was wrong however I see the consequence of your intepretation is that I never need get an allocated error block again I can just call every error an internal error I may be wrong symantically but that doesn’t make any difference. I can’t believe that was the intention. In the link to the IBM errors you posted errors marked as internal errors had their own error number and these numbers just seemed intermingled with other errors ie they look like just an allocated number – though I may have missed something I couldn’t find what you thought the link proved.

I suppose your position may be that you can pass a b30 error on to SWIs/Library functions but you can’t return b30 errors from SWIs. It all starts to get messy.

Regarding the effectiveness of using b30 for validating an error pointer if it is decided it should be 0, the percentage it detects doesn’t matter it cuts out some bad pointers in the same way that a check on a c pointer for NULL cuts out some bad pointers to your function. You wouldn’t not check for NULL just because it doesn’t detect freed memory pointers.

Chris said

That part of the book is correct, but the example code which then chucks the internal error out into the world is (apparently) not.

It has to be said that the example code that has been quoted is extremely odd. Using XOS_CLI to issue star commands that could have been done through OS_File, and then throwing the returned errors anyway. Contrived at best. Potentially unhelpful.

Colin said

your example can be done like this.

No, Colin. You have not understood how ERROR works in Basic (No, I didn’t understand what ERROR does, you may not have understood how the general principle works, stupid me). This line

ERROR&40000001,"Woggle"

calls OS_GenerateError (no it doesn’t, it calls its Error Handler direct – bad example). It is OS_GenerateError we are talking about.

You have modified the error number passed to Wimp_ReportError, which (correctly) doesn’t give two hoots about the error number. Actually, if it’s a Fatal Error (b31) or one of a list of ‘known errors’ it hides the report behind a “may have gone wrong” figleaf – reserved bits and (separately) b30 are excluded from that and reported verbatim.

OS_GenerateError doesn’t (shouldn’t) care either… its job is to direct the error to the Error Handler which, in the titchy Basic example, is PROCerr (in effect).

b30 tells anyone listening in on ErrorV or Service_Error that the rest of the error number only makes sense to the Error Handler, so don’t expect b8-b23 to be a defined error range, or a defined fatal error range, because it’s neither of those things.

Errors work like this…

Application does SWI (or SYS in Basic)

SWI code returns with V set and R0 pointing to an error block

SWI exit code checks for V, and if the SWI X bit is set, returns the error to the caller

Application gets the error in R0 and the V flag set.

It may handle that, or it may (as in the slightly odd example cited by François) throw the error again using OS_GenerateError (Basic does this for OS_Plot calls for some reason). For internal errors, such as “Don’t press this button again”, the application calls OS_GenerateError straight away, no other SWI involved.

OS_GenerateError issues a Service Call

Modules interested in Service_Error get to see the error. They cannot stop the error.

OS_GenerateError calls the ErrorV vector

ErrorV claimants get to hear about the error. Any of them can stop the error (nobody actually does this though).

If something stopped the error, OS_GenerateError returns to the caller

Assuming nobody has stopped it, the error reaches the final ErrorV claimant – the default handler, which copies it to the error buffer and calls the Error Handler

The Error Handler is provided by the application – in Basic’s case it will obey the ON ERROR command

So the take-away detail is this: OS_GenerateError is used (primarily) for the Application to tell its own Error Handler (and anyone else who is listening) that something has gone wrong. b30 is used to signify to those other listeners that the rest of the number only makes sense to the application.

I hope that’s clearer.

It is not valid to raise an error with b30 set if you are not the owner of the Error Handler.

This line calls OS_GenerateError.

Apparently not. Switch between ERROR and OS_GenerateError and you get different results

DIM erb% 256
erm$ = "Hello"
err% = &40000001
!erb% = err%
$(erb% + 4) = erm$+CHR$(0)
ON ERROR PRINT REPORT$:END
REMERROR err%, erm$
 SYS "OS_GenerateError", erb%

Cripes, you’re right. ERROR is an internal call direct to the Error Handler, it doesn’t go through GenerateError, apologies. Hoist by my own Basic petard.

you get different results

Not from the ON ERROR, but clearly ErrorV isn’t involved. Using BASIC was a bad example, sorry. What ‘different results’ do you mean?

OS_GenerateError gives a bad pointer error, ERROR gives the “hello” error so is being trapped by the basic error handler.

Yes I see what you mean. GenerateError should not be modifying the error, as we’ve discussed. ERROR circumvents the mechanism entirely.

I’ve just checked, and Basic has never called GenerateError. I had assumed it did because that seemed logical. The reason is probably because Basic dates back to the ARM second processor, and its OS did not have OS_GenerateError – that was introduced with Arthur. I’d forgotten that.

As an aside, is there any good reason why ERROR does not call GenerateError? Now you’ve brought my attention to it, it looks like an Arthur oversight that has never been corrected. It’s certainly puzzling.

why ERROR does not call GenerateError

It does if you don’t have an internal error handler ie you are not using ON ERROR or switched it off with ON ERROR OFF

Ok, I’m checking carefully… Basic only calls OS_GenerateError under three circumstances:

1. If there isn’t enough memory when starting – it hasn’t registered an error handler at this point
2. If the program executes ERROREXT, which it does after deregistering its error handler
3. If PLOT returns an error — I know, weird!

ERROREXT works the way I expected… I just assumed that EXT simply detached the error handler first.

So to answer my own question, it seems to be entirely deliberate, but mystical. As is the special case of PLOT.

The PLOT thickens

This interesting behaviour applies to all Basic’s plotting, RECTANGLE, CIRCLE etc. I wondered if this dated back to the Graphics Extension ROM era – that ErrorV was being used as a hook to enable undefined PLOTs to be handled… but if anything did handle those errors, Basic would fall into an unrelated bit of code and output two characters unnecessarily.

So… it’s just a bit of weirdness. It ought to be doing OS_Plot, but does XOS_Plot and then OS_GenerateError for no particular reason.

ERROR 0, "some string" also bypasses ON ERROR I always put that down as a way to issue a fatal error. It possibly predates ERROREXT.

Yes, it removes your ON ERROR and restores its default ON ERROR handler.

This is different from ERROR EXT, which entirely removes Basic’s Error Handler and restores the OSes default error handler before calling OS_GenerateError – it is a deliberate attempt to die, and if OS_GenerateError should return, it then calls OS_Exit just to be really sure.

(It is interesting that Basic is correctly coded to cope with GenerateError returning – very little is… perhaps that’s why ERROR doesn’t call OS_GenerateError, because no one writing ERROR1,"Oof" expects execution to continue to the next statement.)

I like all the shouty-shouty in this thread! :-)

Any of them can stop the error (nobody actually does this though).

I believe an old(ish) example of this is ADFS which would trap a request to insert a disc, report it while awaiting the disc being inserted, and then carry on going as if nothing had happened once the correct disc was found in the drive.

I though I was emphasising rather than SHOUTING, but I’m a typographer so I may be strange.

ADFS which would trap a request to insert a disc

No, that’s an UpCall.

There is one commercial program that returned from an error but I’m not going to talk about that.

I just tried a softload for the snapshot build of RISC OS 5.25 (29 Apr 2018) for the Titanium, but NetSurf and Messenger were quite unusable on it as I all the time got the error “SWI &6 returned a bad error pointer”. I suppose this problem is related to this subject, but I think builds since 24th of April are supposed to not have this check anymore?

I suppose this problem is related to this subject, but I think builds since 24th of April are supposed to not have this check anymore?

It won’t check what the pointer points to, but it will still check the pointer itself (must be >= &4000 and word aligned, for all SWIs except XOS_GenerateError). This should be less than what has been being checked for the past two years.

What was the last softload/OS version that you used that worked fine?

I’m not usually running snapshot/softload versions, so the version I usually run is the last RC5 beta for the Titanium, 2017-07-18 (I think the date RISC OS reports is actually a few days before that).

I found that I could not even press F12 without getting this error.

I just tried a softload for the snapshot build of RISC OS 5.25 (29 Apr 2018) for the Titanium, but NetSurf and Messenger were quite unusable on it as I all the time got the error “SWI &6 returned a bad error pointer”.

I am not seeing that here. what do I have to do to provoke it. (Sent from Titanium without any error.)

Hm, interesting. Must be something in my boot then? I’ll investigate.

I found that I could not even press F12 without getting this error.

No, I am not seeing that either.