Re: [Announce] FreeVMS 0.1.3

From: Tom Linden (tom_at_kednos.com)
Date: 03/17/05 

Date: Thu, 17 Mar 2005 07:44:56 -0800

On Thu, 17 Mar 2005 14:56:17 +0000 (UTC), Michael Kraemer
<m.kraemer@gsi.de> wrote:

> In article <opsnsdivu4zgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com>
> writes:
>> On Thu, 17 Mar 2005 14:27:30 +0000 (UTC), Michael Kraemer
>> <m.kraemer@gsi.de> wrote:
>>
>> > Nice trick, worked perfectly back then, but of course
>> > you exactly had to now what you were doing.
>>
>> That is quite different from the usual C buffer overun
>> playing havoc with the stack
>> >
>
> Sure, but the marginal inherent safety advantage PL/I
> seems to offer is based on descriptors, and my example

It is more than marginal and it is based on more than
descriptors. Now there are certainly ways to get into
trouble with PL/I (e.g. use of SUBSTR pseudo function);
however, as I think Bob K pointed out elsewhere in this thread,
"C puts together a unique environment where a
    careful coder could let just one slip by. "
By comparison that could not happen in PL/I

> shows that these may be vulnerable themselves.
> While we're at it: how about AREAs, these large pieces
> of memory, do they have descriptors as well ?

Descriptors will be created if you specify it, or by usage,
but these are transparent to the user. Areas have control
blocks which are used internally by the compiler. PL/I on
VMS is used somewhat differently than on MVS. I would say
that the essential difference is in the level of abstraction.
On MVS you tend to think like an assembler programmer, always
concerned with a variety of control blocks, and therefore the
ability to manipulate them, which is both good and bad.
CONTROLLED variables, for example, have rather complicated
internal houskeeping with linked lists of control blocks
representing the different generations. But none of these
structures are published, and in my view rightly so, since
there is no good reason for the user to manipulate them. If
you look through the PL/I documentaion for VMS, nowhere will you
find a layout of the descriptors, because there is no reason to
manipulate them.

Relevant Pages

  • =?iso-8859-1?Q?Enterprise_PL/I_Internals_(Blocks,_Flags...)?=
    ... In the Enterprise PL/I Migration Guide is written: ... The new compiler uses some different internal control blocks in its ...
    (bit.listserv.ibm-main)
  • Re: IBM2209I : SEVERE
    ... In PL/I arguments are passed by reference by default and descriptors ... All IBM PL/I compilers have required that string lengths, ... compiler did not flag this error then the compiler had a bug. ...
    (comp.lang.pl1)
  • Re: Whither VMS?
    ... Only for VARYING CHAR variables. ... thanks to null termination of read-only strings. ... < A solution superior to C would be if PL/I allowed stuff like ... < You can trash just everything, including your oh-so-secure descriptors. ...
    (comp.os.vms)
  • Re: Multiplicity, Change and MV
    ... those were called FCBs weren't they? ... control blocks. ... Sigh. ...
    (comp.databases.theory)
  • Re: When the goin gets tough! (Was Re: DEFCON 16 and Hacking OpenVMS ** 8.3 Patch available **)
    ... descriptors, or dope vectors are used by the compiler, the programmer doesn't ... descriptors can be trashed as well since they are passed ... as are all parameters in PL/I. ... I have always kept them in production code, I try to write failsafe code, ...
    (comp.os.vms)
Loading