[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Super() bug
First of all, apologies.
In my previous email I have attached a useless binding.
The correct one is called SuperToUser(), to return to the user mode.
This is the only case where the stack needs to be fixed.
Miro Kropáček wrote:
Well, yes, but you breaks another ("bigger") rule, i.e. use Super()
everytime from the same context.
What is a context ?
Where does this rule come from ?
Personally, I don't like it very much, esp. when there are differences
between TOS and FreeMiNT (what about MagiC, Geneva?). One should always
follow basic rules (be careful with Super()).
Of course, switching to supervisor mode is not clean and should be
avoided as much as possible in normal programs. But if your program does
not contain bugs, the supervisor mode is not dangerous for your process.
It simply gives you access to more memory areas. Care must be taken to
not destroy the OS.
Anyway: Super() is supposed to change the user/supervisor mode, this
should be unrelated to the stack. I can hardly understand how restoring
a bogus stack could not be considered as a bug.
The GEMDOS implementation has a special case for the Super() function.
It can easily be traced using a debugger. So we can see exactly what
happens.
My solution is simple and safe. If the OS is clean (like FreeMiNT), it
does not change anything. If the OS is bogus (like TOS), it fixes the
stack. I have been using it for a long time, it works very well. Also,
it solved David's trouble with his USB work. Personally, I will never
use Super() in the classic way again.
You are right, the Super() behavior should be checked on other operating
systems. If my solution is compatible with all of them, it should be used.
use Supexec()
I hate that OS call because it has 2 drawbacks:
1) It uses a function callback. That one is called from the small BIOS
supervisor stack (to be verified again). As a result, the problem is the
same as USERDEFs.
2) The callback has no parameters. So if it really needs some
parameters, global variables must be used, and the function will not be
reentrant. Now I see this is not a real problem, since Supexec() calls
must not be nested.
--
Vincent Rivière