Re: zero-initialization of variables

From	David W Noon <dwnoon@spamtrap.ntlworld.com>
Newsgroups	comp.lang.fortran
Subject	Re: zero-initialization of variables
Date	2011-08-24 17:50 +0100
Organization	Luton Operatic Society
Message-ID	<20110824175041.52c06e8a@dwnoon.ntlworld.com> (permalink)
References	<j2u6uk$8gm$1@speranza.aioe.org> <6d68b74d9724061b347a2b15d9293fb8@dizum.com>

Show all headers | View raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 24 Aug 2011 10:27:23 +0200 (CEST), Nomen Nescio wrote about Re:
zero-initialization of variables:

>glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>
>> Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net>
>> wrote:
>> 
>> > This is for a non reentrant program which by definition is also 
>> > marked non reusable. Therefore the OS guarantees you get a clean 
>> > copy of the load module on each execution so the concept of data 
>> > remaining from a previous execution is not relevant, nothing is 
>> > left in storage because the entire module is loaded for every 
>> > execution. 
>> 
>> They are non-reentrant, though I don't know that the linkage
>> editor knows that.
>
>I believe the object deck that is punched must contain information
>that the program is non-reentrant because even when I explicitly
>specify RENT to the linkage editor step (HEWL/IEWL) the option is
>recognized and overriden to non-reentrant. Non-reentrant programs will
>compile variables into the CSECT and then regardless whether they use
>DS or DC the linkage editor guarantees this area will be set to zero
>as I found.

The object deck contains no attributes about reentrant or reusable
code.  The reason the linkage editor is downgrading to non-reentrant is
because the run-time libraries for all OS/360 FORTRAN compilers (E, G,
G1, H, H Extended and H Extended Plus) were made up entirely of
non-reentrant code, with the result that all FORTRAN load modules were
always marked non-reentrant.

>I cannot find any reentrancy discussion in the FORTRAN H Programmer's
>Guide. I wonder if there was no option and all programs were non
>reentrant. 

FORTRAN code, in those days, was always non-reentrant and non-reusable.

>> Fortran programs, other than initializing variables, should be
>> serially reusable.  As far as I remember, the linkage editor believe
>> you and sets the bits you ask for.
>
>I tested this and the linkage editor overrides my RENT option and
>creates a non-reentrant load module for FORTRAN H. It does not set the
>bits you ask for if you select options that aren't compatible with the
>input object deck or load modules. The linkage editor only processes
>options you specify in the absence of conflicting overrides in the
>object deck.

Not in the object deck, in the RTL.

>I don't remember when they added support for it but in
>assembler you can specify rent or norent and that information is
>passed to the link step afterward,

It isn't.  The RENT assembler option simply checks that no instructions
have a target location inside a CSECT, only inside a DSECT, DXD or
at an explicit base/displacement address.

>so there is certainly a way to do
>this. I believe it's in the object deck itself although the early
>manuals I have don't seem to show the object deck format and I don't
>want to ASSume the later doc applies although most likely it does.

Take a look at the following program:

   http://www.cbttape.org/ftp/cbt/CBT090.zip

It is written in PL/I, but it describes the layouts of the object decks
(and load modules) for all IBM mainframe languages prior to GOFF and
PDS/E load libraries.

[snip]
>> In the usual case, the load module is brought in by program fetch.
>> It can also be read in by a LOAD or LINK macro instruction,
>> which either GETMAINs the space, or brings it into existing
>> space.  In the latter case, I believe that they would not be filled.

The SVCs for LOAD, LINK, XCTL and ATTACH macros will *never* use
existing storage.  A load always does a GETMAIN for fresh memory, as the
module might not load correctly into the same subpool as the rest of
program is using.

This is quite a complicated area of OS/360 -> z/OS systems, and is more
complicated still these days, due to page loading from PDS/E load
libraries.

[snip]
>> Someone else had an example of the MVS/XA linker not doing it.

That would have been myself.

>Did they have an example or was this anecdotal evidence?

I had an example that I used to report it as a security issue to IBM,
circa early 1987.

>Because I have
>tested now on MVS 3.8J,  MVS/ESA, and z/OS and they all behave
>identically, filling unspecified fields in the CSECT with binary
>zeros.

No they don't.

What you are seeing is VSM providing a work area in virtual storage
that is zeroed as part of its commit.  Note that this only applies to
OS/VS1 and later, as OS/360 did not have a concept of "commit" for
central storage [except, perhaps, for the "special" versions for Model
85 and the like].

The linkage editor uses this work area and, because it is zeroed on
allocation, the load module built in this work area has binary zeroes
in its uninitialized data areas.  If you link another load module in the
same invocation of IEWL/HEWL/LINKEDIT there is (was, prior to 1987) the
possibility that detritus from an earlier module in the batch will
appear in later load modules in uninitialized data areas.  This is
because the linkage editor does (did) not zero out the work area before
starting to link a load module.  Since MVS/XA SP 2.1.7, the linkage
editor does zero out its work area before each link.

>> There is also VS Fortran, the Fortran 77 successor to Fortran H.
>> I don't know if there is any common code between them.

VS FORTRAN was a joke in bad taste.

>I mentioned this version earlier. I don't have access to a copy
>although it may be available in the VM/370 distribution.

I don't think IBM has open-sourced VS FORTRAN yet.
- -- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@spamtrap.ntlworld.com (David W Noon)
Remove spam trap to reply by e-mail.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk5VK+cACgkQ9MqaUJQw2MkacgCePputgpAcuBwH0pR30w6UBSBt
uigAnjzuX72E6XJ+tsqxENOS2r9V6Z8v
=kKMf
-----END PGP SIGNATURE-----

Back to comp.lang.fortran | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: zero-initialization of variables Louisa <louisa.hutch@gmail.com> - 2011-08-16 03:15 -0700
  Re: zero-initialization of variables nospam@see.signature (Richard Maine) - 2011-08-16 08:23 -0400
    Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-16 17:59 +0000
      Re: zero-initialization of variables Gordon Sande <Gordon.Sande@gmail.com> - 2011-08-16 15:40 -0300
        Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-16 19:34 +0000
      Re: zero-initialization of variables wclodius@lost-alamos.pet (William Clodius) - 2011-08-16 16:31 -0600
        Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-16 22:41 +0000
      Re: zero-initialization of variables nospam@see.signature (Richard Maine) - 2011-08-16 20:48 -0400
        Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-17 01:20 +0000
          Re: zero-initialization of variables nospam@see.signature (Richard Maine) - 2011-08-16 21:33 -0400
            Re: zero-initialization of variables Louisa <louisa.hutch@gmail.com> - 2011-08-16 18:46 -0700
              Re: zero-initialization of variables nospam@see.signature (Richard Maine) - 2011-08-16 22:01 -0400
                Re: zero-initialization of variables Louisa <louisa.hutch@gmail.com> - 2011-08-23 02:43 -0700
                Re: zero-initialization of variables Thomas Koenig <tkoenig@netcologne.de> - 2011-08-23 17:29 +0000
              Re: zero-initialization of variables Gib Bogle <g.bogle@auckland.ac.nz> - 2011-08-28 20:50 +1200
                Re: zero-initialization of variables Gib Bogle <g.bogle@auckland.ac.nz> - 2011-08-28 20:59 +1200
          Re: zero-initialization of variables Dick Hendrickson <dick.hendrickson@att.net> - 2011-08-17 11:30 -0500
        Re: zero-initialization of variables Paul Anton Letnes <paul.anton.letnes@gmail.com> - 2011-08-17 19:02 +0100
          Re: zero-initialization of variables dpb <none@non.net> - 2011-08-17 13:43 -0500
    Re: zero-initialization of variables Louisa <louisa.hutch@gmail.com> - 2011-08-16 18:28 -0700
      Re: zero-initialization of variables Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-08-17 07:01 -0600
        Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-17 17:52 +0000
          Re: zero-initialization of variables Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-08-17 13:07 -0600
            Re: zero-initialization of variables abrsvc <dansabrservices@yahoo.com> - 2011-08-17 12:23 -0700
      Re: zero-initialization of variables Paul van Delst <paul.vandelst@noaa.gov> - 2011-08-17 14:23 -0400
        Re: zero-initialization of variables Nomen Nescio <nobody@dizum.com> - 2011-08-19 09:50 +0200
          Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-19 09:35 +0000
            Re: zero-initialization of variables Nomen Nescio <nobody@dizum.com> - 2011-08-19 13:04 +0200
              Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-19 18:33 +0000
                Re: zero-initialization of variables Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net> - 2011-08-22 19:15 +0200
                Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-22 18:25 +0000
                Re: zero-initialization of variables Nomen Nescio <nobody@dizum.com> - 2011-08-24 10:27 +0200
                Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-24 10:11 +0000
                Re: zero-initialization of variables Nomen Nescio <nobody@dizum.com> - 2011-08-24 14:22 +0200
                Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-24 22:02 +0000
                Re: zero-initialization of variables Louisa <louisa.hutch@gmail.com> - 2011-08-24 19:00 -0700
                Re: zero-initialization of variables David W Noon <dwnoon@spamtrap.ntlworld.com> - 2011-08-24 17:50 +0100
                Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-24 22:19 +0000
                Re: zero-initialization of variables David W Noon <dwnoon@spamtrap.ntlworld.com> - 2011-08-25 01:21 +0100
                Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-25 00:55 +0000
                Re: zero-initialization of variables Louisa <louisa.hutch@gmail.com> - 2011-08-24 18:53 -0700
                Re: zero-initialization of variables Dick Hendrickson <dick.hendrickson@att.net> - 2011-08-24 21:42 -0500
                Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-25 03:24 +0000
                Re: zero-initialization of variables Nomen Nescio <nobody@dizum.com> - 2011-08-25 15:13 +0200
                Re: zero-initialization of variables Nomen Nescio <nobody@dizum.com> - 2011-08-25 11:02 +0200
                Re: zero-initialization of variables David W Noon <dwnoon@spamtrap.ntlworld.com> - 2011-08-25 19:57 +0100
                Re: zero-initialization of variables Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net> - 2011-08-24 17:10 +0200
              Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-19 23:50 +0000
                Re: zero-initialization of variables David W Noon <dwnoon@spamtrap.ntlworld.com> - 2011-08-20 15:51 +0100
                Re: zero-initialization of variables Nomen Nescio <nobody@dizum.com> - 2011-08-22 15:56 +0200
          Re: zero-initialization of variables Nomen Nescio <nobody@dizum.com> - 2011-08-19 12:22 +0200
          Re: zero-initialization of variables nospam@see.signature (Richard Maine) - 2011-08-19 08:21 -0400
      Re: zero-initialization of variables Lynn McGuire <lmc@winsim.com> - 2011-08-18 22:32 -0500
        Re: zero-initialization of variables Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net> - 2011-08-19 20:55 +0200
        Re: zero-initialization of variables Tim Prince <tprince@computer.org> - 2011-08-19 17:04 -0400
          Re: zero-initialization of variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-08-19 21:38 +0000

csiph-web