On Wed, 31 Jul 2013 08:45:10 -0400, John Gilmore wrote:
>This is a vexed topic.
>
>PL/I always had full support for the FIXEDOVERFLOW condition for
>binary fixed values, but when much of the backend support for C and
>PL/I was merged, support for it, never provided in C, was dropped for
>PL/I too, not quite but almost silently. The FIXEDOVERFLOW condition
>is now supported only for decimal fixed, i.e., packed-decimal, values.
>
Thereby opening one more avenue for exploits. I believe I saw that in
the PSW in the CEEDUMP. Only because packed-decimal is not a
conventional data type in C.
I saw that /usr/include/signal.h says:
...
/* Flags returned in the si_code member of a siginfo_t */
...
#define FPE_INTDIV 31 /* SIGFPE caused by an integer *
* divide by zero */
#define FPE_INTOVF 32 /* SIGFPE caused by an integer *
* overflow */
... and wondered, error injection; how can I force FPE_INTOVF?
I infer that it's not easy.
>Before these kinds of things---There have been gratuitousx additions
>too, like package in a language that supports multiple entries in a
>procedure block, but these can be ignored---started to happen to IBM
>implementations of PL/I I had had no animus against C. I thought of
>it as a FORTRAN dialect that people should be free to use if they
>wished to do so, as they are free to use, say, RPG II. That has
>changed as its juvenile disorders have infected PL/I support too. I
>am now actively hostile to it.
>
I sympathize. But, heck; I'm even actively hostile to HLASM's
toleration of division by zero in EQU (and SETA?) instructions.
How could they!? (Yah; I know; "diachronic". But even when
the world was young ... What? not enough storage to hold an
exception handler, so they simply ignored it?)
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
