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

From: Robert Wagner (robert.deletethis_at_wagner.net)
Date: 06/12/04

  • Next message: Peter E. C. Dashwood: "Re: OT everyone knows everyone. WAS: PPI numbers postponed until...sometime im the future!" 
    Date: Sat, 12 Jun 2004 00:14:13 GMT

    "Chuck Stevens" <charles.stevens@unisys.com> wrote:

    >"Robert Wagner" <robert.deletethis@wagner.net> wrote in message
    >news:40c9685a.589226654@news.optonline.net...
    >
    >> A general-purpose solution would be to walk back the call stack returning
    >the
    >> names of all programs from the program of interest back to Main.
    >
    >That is presuming that the implementation has an accessible structure such
    >as a "call stack".

    Every called program has a way of returning to its caller.

    >> Generally, you can't pass strings on the stack. You can only pass words,
    >such as
    >> a pointer to the string. Make that 'CALL a-program USING (default BY
    >REFERENCE)
    >> a-program'.
    >
    >Last sentence first: "CALL a-program USING BY CONTENT a-program" would I
    >think be preferable. The objective here is to ensure that a-program cannot
    >step on this particular parameter.

    But it can. It just cannot modify it back in the caller's memory.

    I don't think this is a realistic concern. Programs generally don't recklessly
    modify parameters.

    >In our implementation, there is no pre-execution-time linking phase; the
    >determination as to whether the target procedure is nested or
    >separately-compiled has to be made at execution time and is a rather
    >expensive process. Thus, while "CALL <dataname>" works it is almost
    >invariably much more costly than "CALL <literal>".

    It is in nearly all environments. It need not be. Sure, dataname can change, but
    99.99 percent of the time it doesn't. INLINE code could (should) check that it's
    the same and then call directly, with little more overhead than a static link. I
    used to write enhancers that reached back and modified generated code to do
    exactly that.

    > where does the standard require that the implementor keep track of
    >information about calling history in some sort of hardware stack? Where
    >does the standard prohibit putting strings (do you mean strictly
    >"alphanumeric literals" or do you include "alphanumeric data items"?) on
    >that stack?
    >
    >BY CONTENT non-numeric parameters of arbitrary length are allowed.
    >
    >How the implementation *accomplishes* passing, say, a 30,000-byte record as
    >a parameter BY CONTENT is none of the end user's business; the only concern
    >is how the caller sees it if the called program happens to step on its
    >contents (and the correct expectation is that it be unchanged).

    True but discordant with the culture of operating systems and other languages.
    Micro Focus says:

    "If the program being called is not COBOL, the size of the additional data item
    should not exceed the maximum size of the system area (typically the size of a
    POINTER on the system); otherwise the system might become catastrophically
    corrupt."

    You wouldn't want to be the one found to have "catastrophically corrupted" the
    system. I know .. FUD.

    >What's this about words? It may be *common* to use some sort of fixed
    >structure to describe a parameter passed by content -- but there is
    >absolutely no requirement that that structure be inherently different from
    >the structure that would be used for parameters passed by reference, or that
    >the structure be related in any way to any other structure that might be
    >used in the operating environment.

    The idea of BY CONTENT and BY VALUE is based on paranoia and disrespect. Its
    premise is that called programs may irrationally corrupt parameter values. In
    the real world, that's not a realistic concern.

    >Moreover, there is nothing except resources and incentive preventing an
    >obsolete-computer buff from implementing a fully-2002-compliant COBOL
    >implementation on a Burroughs B3500, or even an IBM 1401, for which
    >architectures the concept of "fixed-length words" as I understand the
    >concept does not exist.

    On the 1401 I wrote a rudimentary operating system because the machine didn't
    come with one. On the B3500/4700 I completely rewrite the communications
    software and print spooler in Cobol and contributed to the design of MCPV.

    You're correct: they didn't have words nor stacks, but they did have a pointer
    back to the caller.

  • Next message: Peter E. C. Dashwood: "Re: OT everyone knows everyone. WAS: PPI numbers postponed until...sometime im the future!"

    Relevant Pages

    • Re: Stack Overflow
      ... Sub Caller() ... '<<< COMPILER STORES THIS LOCATION ... Sub CalledFunction() ... (Think of it like a stack of plates. ...
      (microsoft.public.excel.programming)
    • Re: How function calls work
      ... >I'm interested in how the compiler implements function calls, ... >know where these are in memory relative to the current stack pointer ... caller saves registers it wants saved (unless it knows function plans to ... function allocates stack space for all its local data, ...
      (comp.lang.cpp)
    • Re: StdCall vs. CDecl
      ... __cdecl means that the caller needs to remove the args. ... caller to clean up the stack, while the caller will expect the function to ... why does our VB.NET code work well when the calling convention ...
      (microsoft.public.dotnet.framework.interop)
    • Re: Parameter Overflow Attack?
      ... > corrupt will be its user-mode memory, not the system-mode memory. ... normally responsible for removing the parameters from the stack. ... a problem it will be after return to user space execution of the program ...
      (comp.security.misc)
    • Re: SP 2 compatibility problem
      ... > 0x777 The caller is unlocking a system cache address that is not currently locked. ... > 0x781 The PTEs mapping the argument system cache view have been corrupted. ... > 0x3451 The PTEs of an outswapped kernel thread stack are corrupt. ...
      (microsoft.public.windowsxp.general)