Re: We have met the enemy, and the enemy is ... you.

[jnf <jnf () nosec net>]

> INTO would trigger an interrupt (which one depends on the OS) only
> when the OF flag is set, which does not cover all integer overflows.
> To handle all int overflows you also have to check the carry flag,
> so a JO/JC pair looks like a much better solution to me.

INTO generates int 4, the first 32 interrupt vector numbers are reserved
by intel, so it doesn't vary per OS. When I mentioned INTO/BOUND I was
mostly just using them as examples. I fail to really understand why we do
not make use of certain features of the underlying hardware that would
solve a lot of these problems.

For instance, in regards to int overflows, nearly every
(perhaps all of them?) architecture supports the ability to detect int
overflow, however I do not see compilers making really any use of this.

I suppose as someone pointed out that BOUND is horrible on performance, I
haven't bench marked it so for the moment at least I will take their word
on it, this provides the only real explanation that satisfies thus far.


> For high security people can use the ADA language, which adds
> by default run-time checks for boundaries and integer overflows
> (and more).

We could also stop writing programs or start using carrier pidgeons, etc.
While I generally agree with you the premise wasn't to try to get the
world to switch its primary programming languages, but rather just to
investigate why we have some fairly complex solutions to problems that the
underlying hardware already has fixes for.

> regards,
> --spath