> Um, I think you *have* to check the results, because you cannot afford to
> dereference something bad. We're in OS-land (a.k.a., systems programming land),
> not application-land. There are no guard-rails (a.k.a., memory protection
> mechanisms). We do not want to become (in)famous for our version of the BSOD
> (even though I am sure we could pick a more, well, tasteful color, and, perhaps,
> put a more interesting text up on the screen like "Hey, at least you didn't PAY
> for this!").
I'm aware that we have to check our results. Having exceptions
just obviates the need to do it on every single call -- you're writing the
'check' into the function, not its caller. At any rate, your suggestion
below seems fairly reasonable. (If painful in terms of coding time.)
> Now, I'm a little out of my depth here, but here goes (somebody correct me if
> I'm wrong) -- it is my understanding that native methods are inherently
> non-portable, so we have some freedom to define how they should be
> compiled/written (if, in fact, we support them in the medium to long term -- we
> certainly won't support them in the short term). Furthermore, given that we
> currently envision no memory protection (e.g., separate address spaces for
> native methods), allowing native methods is an huge invitation to Bad Things
> like BSODs, and viruses, etc.
It might be premature to be worrying about native methods, but as
long as I'm going to be rewriting runOpCode on a line-by-line basis, I
figure I might as well be doing it /right/ and not have to do it /again/
when we do allow native methods, however they may be protected.
> When you say "native exception," do you mean C++ "throw," or vanilla-C reference
> to memory that ain't there (a.k.a., bus error, address error, memory error)?
C++ "throw."
> p.s., you want me to stop putting your specific email address on the "To" list
> so you get the mail slower, but get only one copy?
I don't particularly care either way. It's nice when I'm actually
here when the mail arrives, and worth it, but otherwise it's not much of
an annoyance.
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
