Re: Is it possible to use the value of the PROGRAM ID within the source code?

From: Chuck Stevens (charles.stevens_at_unisys.com)
Date: 06/17/04

  • Next message: Chuck Stevens: "Re: Is it possible to use the value of the PROGRAM ID within the source code?" 
    Date: Thu, 17 Jun 2004 10:15:17 -0700

    "Robert Wagner" <robert.deletethis@wagner.net> wrote in message
    news:40d0e65d.32860852@news.optonline.net...

    > Silly me. I thought the hardware afforded protection independent of
    language.
    > Now you claim the language's 'hiding' features make the stack invisible to
    > 'application code'.

    EXIT, RETN, and the setting of the RCW on ENTR are independent of language.
    The hardware scope rules and the D registers are independent of language.

    > Obviously, we'll have to deny application programmers access to languages
    that
    > generate an EXIT or RETN, especially assembly language. That would be easy
    on
    > Unisys because there is no assembly language.

    Application programs cause the compilers to generate EXIT, RETN, MKST and
    ENTR all the time. What application programs cannot do is make use of raw
    memory addresses, access other programs' stacks, or even access their own
    stack as if it were data and "leapfrog" from there into a stack owned by
    another process.

    Moreover, precisely because memory *is* dynamically allocated, there is no
    guarantee from one access to the next that a given piece of information will
    be in the same physical location, so *raw* memory addresses are meaningless.

    If you could decode a RCW or access the stack directly as if it were a
    memory space, what would you do with that information, given that even that
    space is protected by the scope rules?

    > Tying programmers' hands is even worse security than 'information hiding'.

    Users are welcome to write their own compilers. However, it is the compiler
    author's responsibility to ensure that the code it generates is compatible
    with all currently-supported machines, and there is no guarantee that a
    given convention or approach to a process will survive for any period of
    time. And if a user elects to change one of our compilers, any problem they
    report in that language must be reproduced by them using, and reported
    against, a released compiler; we do not support software that has been
    locally patched.

    Why is it necessary for a user program to have access to another process'
    memory space without that process' direct involvement in the access? So
    far as I know, very few, if any, actual *users* of this architecture have
    found the mechanisms of memory management and the stack architecture
    *restrictive*.

    > > It doesn't, but it appears in IBM, Micro Focus, Fujitsu and others. In
    other
    > words, 98+% of available Cobol compilers.

    Are we using the adolescent argument "But MOM!!!! Everybody who's *ANYbody*
    has one!", eh? Or are we back to "What is or is not standards-compliant
    COBOL has nothing to do with what the standards say, only with what I
    perceive to be Admirable Practice!"?

    Again, any Unisys MCP customer is welcome to file a New Feature Suggestion
    against COBOL85 to request USAGE POINTER in that dialect. I daresay IBM,
    Micro Focus, Fujitsu and others have incorporated it because *their*
    customers have found it to be a useful feature. As far as ANSI X3.23-1985
    COBOL goes, it is an extension, and in our case there has been so little
    demand for this extension from our users -- that is to say, none -- and
    there has been so little evidence that this feature would be of particular
    benefit in the Unisys MCP environment -- none that I've seen so far, and a
    lot of security risks -- that it isn't even on the list of such features for
    consideration at this time.

        -Chuck Stevens

  • Next message: Chuck Stevens: "Re: Is it possible to use the value of the PROGRAM ID within the source code?"

    Relevant Pages

    • Re: operation on module arguments
      ... But the logic to have this feature in the ... language is pretty reasonable, so I was not too greedy, was I? ... memory for storing a real variable, and let the variable name 'A' refer to that bit of memory." ... It means, for example, that the compiler can't pass A around like a real variable, because when the compiler passes it to a subroutine that might modify it, the compiler also has to pass along the instructions that go with it. ...
      (comp.lang.fortran)
    • Re: Turbo questions
      ... don't somwhow exist outside the language :-). ... But they do - those things are just ways of laying out memory. ... those things is made easier is the feature. ... controls the platform and is free to introduce technologies. ...
      (borland.public.delphi.non-technical)
    • Re: hacker challenge - traverse a list
      ... in order only using Oadditional memory. ... can't use recursion or simulate it with a stack. ... Use whatever language ... Scanning list structures without stacks or tag bits. ...
      (comp.programming)
    • Re: hacker challenge - traverse a list
      ... in order only using Oadditional memory. ... can't use recursion or simulate it with a stack. ...  We don't need no steenking rules! ...  Use whatever language ...
      (comp.programming)
    • Re: pop quiz for Forth novices
      ... the memory allocation words that Forth provides. ... That doesn't require an addition to the language ... least one C implementation that didn't use a stack. ... Many C programs have their own memory allocator. ...
      (comp.lang.forth)