As many have advised on this board, we are looking to remove the /save
compiler option from our compiles.  The /save option initializes all local
variable to zero and saves their values between subroutine calls.  Does
anyone have experience doing this and have any advice ?  We have about
600,000 lines of code and 100,000 local variables to initialize.

I was wondering what would be the best procedure for doing this:
1. initialize all local variables to zero in a data statement
2. initialize all local variables to zero in a statement at the beginning of the
    subroutine (my favorite)
3. something else ?

Thanks,
Lynn

In article 
<2sGdncUF-9gCRK3RnZ2dnUVZ_vadnZ2d@posted.internetamerica>,
 "Lynn McGuire" <lmc@winsim.com> wrote:

> As many have advised on this board, we are looking to remove the /save
> compiler option from our compiles.  The /save option initializes all local
> variable to zero and saves their values between subroutine calls.  Does
> anyone have experience doing this and have any advice ?  We have about
> 600,000 lines of code and 100,000 local variables to initialize.
> 
> I was wondering what would be the best procedure for doing this:
> 1. initialize all local variables to zero in a data statement
> 2. initialize all local variables to zero in a statement at the beginning of 
> the
>     subroutine (my favorite)

These do different things, and you will need to figure out which 
kind of initialization is required.  Also, along with this, you will 
need to determine which variables really do need to be saved so that 
their values are retained between calls.  With the current code and 
nonstandard /save compiler directives, you are almost certainly 
initializing and saving variables that do not need it, but since 
your code does not work without these options, there are apparently 
some variables that do need one or the other.  You don't want to 
save variables, particularly large arrays, that do not need to be 
saved.

> 3. something else ?

Something I recommended a while back is to find a compiler that 
allows default initializations to arbitrary bit patterns.  Then you 
can set all variables that are otherwise not initialized the right 
way (i.e. with save statements, data statements, and normal 
assignments) to various values (large positive or negative values 
for integers, signaling/quiet NaNs or positive or negative HUGE() 
for floating point) and watch where the program errs.  You can work 
through your program one routine at a time or in blocks of routines 
as appropriate.  Hopefully, the bad code is limited and localized.  
Perhaps you can identify it as mostly being written by a single bad 
programmer, and track it down that way.  When your code is finally 
correct, you should be able to set this default memory 
initialization to any value at all, and every final and intermediate 
result ever computed throughout your entire program will have the 
same correct value.

$.02 -Ron Shepard

Lynn McGuire <lmc@winsim.com> wrote:

> As many have advised on this board, we are looking to remove the /save
> compiler option from our compiles.  The /save option initializes all local
> variable to zero and saves their values between subroutine calls.  Does
> anyone have experience doing this and have any advice ?  We have about
> 600,000 lines of code and 100,000 local variables to initialize.
> 
> I was wondering what would be the best procedure for doing this:
> 1. initialize all local variables to zero in a data statement
> 2. initialize all local variables to zero in a statement at the beginning
>     of the subroutine (my favorite)
> 3. something else ?

Note that SAVE and zero initialization are very different things. It is
not uncommon for old codes to require both of them, but that doesn't
mean they are equivalent. Between choices 1 and 2, probably 1 is the
"safest" in most cases, but there are exceptions.

Choice 1 does zero initialization (and implicitly also SAVE because
initialized variables are implicitly saved as of f90). If you code needs
both, then that's what you want.

If your code actually needs SAVE, then 2 is not what you want. Choice 2
would be pretty much the opposite of SAVE in that it zeros the variables
on each entry, throwing away whatever values they had before.

Now there are cases where choice 2 is superior. But they are all cases
where the code does not need SAVE. In particular, if you have code that
assumes zero initialialization, does not need SAVE, and might get
converted to being invoked multiple times in a single program, then
choice 2 does the needed zero initialization for each invocation.
Parallelization is a prime area where this could be relevant.

I'm not addressing option 3. There might be possibilities there, such as
along the line that Ron mentioned. I'm just pointing out the important
difference between 1 and 2.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

> Something I recommended a while back is to find a compiler that
> allows default initializations to arbitrary bit patterns.  Then you
> can set all variables that are otherwise not initialized the right
> way (i.e. with save statements, data statements, and normal
> assignments) to various values (large positive or negative values
> for integers, signaling/quiet NaNs or positive or negative HUGE()
> for floating point) and watch where the program errs.  You can work
> through your program one routine at a time or in blocks of routines
> as appropriate.  Hopefully, the bad code is limited and localized.

I think that I want to stay with our current compiler until we get everything
to working without /save.  That way we have a baseline and can run two
debug sessions, one with /save and one without.

> Perhaps you can identify it as mostly being written by a single bad
> programmer, and track it down that way.  When your code is finally

Over 100 programmers wrote our software.  Maybe 200 over the 40+
years.

Thanks,
Lynn

On 7/4/2010 9:03 PM, Lynn McGuire wrote:
>> Something I recommended a while back is to find a compiler that
>> allows default initializations to arbitrary bit patterns.  Then you
>> can set all variables that are otherwise not initialized the right
>> way (i.e. with save statements, data statements, and normal
>> assignments) to various values (large positive or negative values
>> for integers, signaling/quiet NaNs or positive or negative HUGE()
>> for floating point) and watch where the program errs.  You can work
>> through your program one routine at a time or in blocks of routines
>> as appropriate.  Hopefully, the bad code is limited and localized.
>
> I think that I want to stay with our current compiler until we get everything
> to working without /save.  That way we have a baseline and can run two
> debug sessions, one with /save and one without.

I think Ron is suggesting using a different compiler to help you find 
uninitialized variables and get things to work without /save.  In the 
best-case scenario, you could find a compiler that could let you specify 
/save or /init_to_funny_bits on a file by file basis.  If everything 
works with /save, change /save to /init_to_funny on one source file, add 
the save attribute if and where it is needed, move on to another file, 
and repeat until done.

Louis

On 2010-07-05 00:03:46 -0300, "Lynn McGuire" <lmc@winsim.com> said:

>> Something I recommended a while back is to find a compiler that
>> allows default initializations to arbitrary bit patterns.  Then you
>> can set all variables that are otherwise not initialized the right
>> way (i.e. with save statements, data statements, and normal
>> assignments) to various values (large positive or negative values
>> for integers, signaling/quiet NaNs or positive or negative HUGE()
>> for floating point) and watch where the program errs.  You can work
>> through your program one routine at a time or in blocks of routines
>> as appropriate.  Hopefully, the bad code is limited and localized.
> 
> I think that I want to stay with our current compiler until we get everything
> to working without /save.  That way we have a baseline and can run two
> debug sessions, one with /save and one without.

You may also run into the situation where the progrmmer assumed (incorrectly)
that the zero initialization would happen on each entry but instead the
values are those left over from the previous entry. So you have been living
with a (hopefully minor) bug for all this time. Fixing things to assign to
zero will change things. Your problem will be to figure out which is right.
Simply keeping things the same as they were may involve preserving some number
of bugs!

The thing to worry about is the bug that has been producing plausible
answers that have become the accepted answers.

>> Perhaps you can identify it as mostly being written by a single bad
>> programmer, and track it down that way.  When your code is finally
> 
> Over 100 programmers wrote our software.  Maybe 200 over the 40+
> years.
> 
> Thanks,
> Lynn

Lynn McGuire wrote:

> As many have advised on this board, we are looking to remove the /save
> compiler option from our compiles.  The /save option initializes all local
> variable to zero and saves their values between subroutine calls.  Does
> anyone have experience doing this and have any advice ?  We have about
> 600,000 lines of code and 100,000 local variables to initialize.
> 
> I was wondering what would be the best procedure for doing this:
> 1. initialize all local variables to zero in a data statement
> 2. initialize all local variables to zero in a statement at the beginning
> of the
>     subroutine (my favorite)
> 3. something else ?
> 
> Thanks,
> Lynn

Lynn: given the size of the task facing you, it is more important that you
start out with a full understanding of the implications of choosing each of
the alternatives that you have listed, instead of adopting one of them on
the basis of recommendations alone.

Here is an example that illustrates my point:

--------------------------------
program undefvar

  integer :: ivar

  call sub
  ivar=-100              ! diversion
  call sub
  write(*,'(/,I4)')ivar  ! diversion

end program undefvar

subroutine sub()

  integer :: iv  ! should have been initialized to -10 and 'save'd
  if(iv < 0)iv=-iv
  iv=iv+10
  write(*,*)iv
  return

end subroutine sub
--------------------------------

Let us assume that the original programmer's intention was to initialize iv
to -10 in the subroutine, and have iv retain its value from one subroutine
call to the next. The bugs consist of not doing the initialization and not
specifying the 'save' attribute. The programmer's expected results from the
program:

 20
 30

-100


If you use your alternatives 1 or 2, you will be deceiving yourself. Try
your alternatives on this silly test program. The program may run, but not
as intended. The results may be wrong, but it may evade you to recognize
that they are faulty.

Likewise, if you use a compiler's option to do zero-initialization using a
compiler switch, or add the 'save' attribute to the variable iv, the
modified program will still not function correctly, since the intended
initialization to -10 has not been implemented. Beyond the
common "initialize to zero" feature, no compiler can read the programmer's
intentions. Along the same lines, what  are proper initial values for
LOGICAL and CHARACTER variables, for which "initialize to zero" makes no
sense?

Now, for your big application, consider that, instead of the integer iv, the
ideal-gas constant R is the one that is not initialized wherever it is
needed, and imagine the consequences.

What recourse is there left? I recommend that you use a compiler that will
most effectively help you hunt down instances of uninitialized variables.
Lahey/Fujitsu, NAG and, on Windows, Salford/Silverfrost compilers have good
capabilities of this sort. NAG is especially good in pinpointing bugs with
respect to INTENT(OUT) variables.

Compilers that set out to produce fast executables are not necessarily
suited for the task before you.

HTH.

-- mecej4

> Now there are cases where choice 2 is superior. But they are all cases
> where the code does not need SAVE. In particular, if you have code that
> assumes zero initialialization, does not need SAVE, and might get
> converted to being invoked multiple times in a single program, then
> choice 2 does the needed zero initialization for each invocation.
> Parallelization is a prime area where this could be relevant.

I think that our code needs zeroing upon EACH entry of our subroutines.
I have been trying this out and have gotten several benchmark files to run
to completion now by adding the zeroing of a few key variables (the indexes
for the arrays variables have been killers).

I doubt that we have very many actual variables to be SAVEd that have
not already been marked as such.

Thanks,
Lynn

> You may also run into the situation where the progrmmer assumed (incorrectly)
> that the zero initialization would happen on each entry but instead the
> values are those left over from the previous entry. So you have been living
> with a (hopefully minor) bug for all this time. Fixing things to assign to
> zero will change things. Your problem will be to figure out which is right.
> Simply keeping things the same as they were may involve preserving some number
> of bugs!
>
> The thing to worry about is the bug that has been producing plausible
> answers that have become the accepted answers.

That is where our engineering expertise comes in and we can tell the change
is for the better or for the worse.

Thanks,
Lynn

Lynn McGuire wrote:
....

> I think that our code needs zeroing upon EACH entry of our subroutines.
> I have been trying this out and have gotten several benchmark files to run
> to completion now by adding the zeroing of a few key variables (the indexes
> for the arrays variables have been killers).
....

If that's the case, it's been wrong w/ the /SAVE option because it does 
_NOT_ do that at all.

 >> type wat.for

program wat
   x = 1.0

   call foo(x)
   call foo(x)
end

Subroutine foo(x)

   x = x+1.

   print *, y

   y = y+1.0
End


C:\Temp> wfl386 /save wat.for
Watcom F77/32 Compile and Link Utility Version 11.0
Copyright by Sybase, Inc., and its subsidiaries, 1990, 1997.
All rights reserved.  Watcom is a trademark of Sybase, Inc.
         wfc386 wat.for  /save
Watcom FORTRAN 77/32 Optimizing Compiler Version 11.0  2010/07/05 18:15:38
Copyright by Sybase, Inc., and its subsidiaries, 1984, 1997.
All rights reserved.  Watcom is a trademark of Sybase, Inc.
wat.for: 11 statements, 72 bytes, 1 extensions, 0 warnings, 0 errors

WATCOM Linker Version 11.0
Copyright by Sybase, Inc., and its subsidiaries, 1985, 1997.
All rights reserved.  Watcom is a trademark of Sybase, Inc.
loading object files
searching libraries
creating a Windows NT character-mode executable

C:\Temp> wat
        0.0000000
        1.0000000

C:\Temp>

--

dpb wrote:
> Lynn McGuire wrote:
> ...
> 
>> I think that our code needs zeroing upon EACH entry of our subroutines.
>> I have been trying this out and have gotten several benchmark files to 
>> run
>> to completion now by adding the zeroing of a few key variables (the 
>> indexes
>> for the arrays variables have been killers).
> ...
> 
> If that's the case, it's been wrong w/ the /SAVE option because it does 
> _NOT_ do that at all.
> 
>  >> type wat.for
> 
> program wat
>   x = 1.0
> 
>   call foo(x)
>   call foo(x)
> end
> 
> Subroutine foo(x)
> 
>   x = x+1.
> 
>   print *, y
> 
>   y = y+1.0
> End
> 
> 
> C:\Temp> wfl386 /save wat.for
> Watcom F77/32 Compile and Link Utility Version 11.0
> Copyright by Sybase, Inc., and its subsidiaries, 1990, 1997.
> All rights reserved.  Watcom is a trademark of Sybase, Inc.
>         wfc386 wat.for  /save
> Watcom FORTRAN 77/32 Optimizing Compiler Version 11.0  2010/07/05 18:15:38
> Copyright by Sybase, Inc., and its subsidiaries, 1984, 1997.
> All rights reserved.  Watcom is a trademark of Sybase, Inc.
> wat.for: 11 statements, 72 bytes, 1 extensions, 0 warnings, 0 errors
> 
> WATCOM Linker Version 11.0
> Copyright by Sybase, Inc., and its subsidiaries, 1985, 1997.
> All rights reserved.  Watcom is a trademark of Sybase, Inc.
> loading object files
> searching libraries
> creating a Windows NT character-mode executable
> 
> C:\Temp> wat
>        0.0000000
>        1.0000000
> 
> C:\Temp>

And,

C:\Temp> wfl386 /quiet wat.for

C:\Temp> wat
        0.0000000
        0.0000000

C:\Temp>

W/O /SAVE, y is zero on entry; with it retains its previous value.

So, if as I understand it, you've had global /SAVE and think the results 
are correct, wherever there's an uninitialized variable it's not been 
being reset and so adding that in will definitely be a change.  Now, 
whether that's important or not is indeterminate from here, but it 
surely will be a different code behavior if do so.

As noted earlier by somebody, the DATA statement has the same 
initialization effect as /SAVE and implicitly will cause /SAVE

C:\Temp> *type wat.for
     program watfor
       x = 1.0

       call foo(x)
       call foo(x)
     end

     Subroutine foo(x)
        data y /0.0/

        x = x+1.
        print *, y
        y = y+1.0
      End

C:\Temp> wfl386 /quiet wat.for

C:\Temp> wat
        0.0000000
        1.0000000

C:\Temp>

--

>> I think that our code needs zeroing upon EACH entry of our subroutines.
>> I have been trying this out and have gotten several benchmark files to run
>> to completion now by adding the zeroing of a few key variables (the indexes
>> for the arrays variables have been killers).
> ...
>
> If that's the case, it's been wrong w/ the /SAVE option because it does _NOT_ do that at all.

I do not disagree with that statement.  That is why I think that the explicit
zeroing of our local variables will be better for the code as that initial value
of zero in each subroutine call will be much more consistent with the
resultant calculations.

Thanks,
Lynn

Lynn McGuire wrote:
>>> I think that our code needs zeroing upon EACH entry of our subroutines.
>>> I have been trying this out and have gotten several benchmark files to run
>>> to completion now by adding the zeroing of a few key variables (the indexes
>>> for the arrays variables have been killers).
>> ...
>>
>> If that's the case, it's been wrong w/ the /SAVE option because
>> it does _NOT_ do that at all.
> 
> I do not disagree with that statement.  That is why I think that the explicit
> zeroing of our local variables will be better for the code as that initial value
> of zero in each subroutine call will be much more consistent with the
> resultant calculations.

I'm truly confused now about what you think is the right answer...and 
how you know whether the answer is, in fact, correct.

It makes no sense to me as the 2nd sentence of the first paragraph seems 
to completely negate the assertion that the code has been running w/ OW 
owing to /SAVE and its initialization (which is one-time only).

--

> C:\Temp> wfl386 /quiet wat.for
>
> C:\Temp> wat
>        0.0000000
>        0.0000000

> W/O /SAVE, y is zero on entry; with it retains its previous value.

That is not the behavior that I am seeing when the /save is dropped from
OW 1.9.  I see that the y variable has a totally random, but consistent,
value upon usage.  I see that you are using Watcom 11.0, not OW 1.9.

C:\dii>wfl386 /quiet wat.for

C:\dii>wat
  6.0233654E+036
  6.0233654E+036

> As noted earlier by somebody, the DATA statement has the same initialization effect as /SAVE and implicitly will cause /SAVE

Since I do not want that behavior, explicit initialization of the local variables
will be much better for me.

Thanks,
Lynn

dpb <none@non.net> wrote:

> Lynn McGuire wrote:
> >>> I think that our code needs zeroing upon EACH entry of our subroutines.

> I'm truly confused now about what you think is the right answer...and
> how you know whether the answer is, in fact, correct.
> 
> It makes no sense to me as the 2nd sentence of the first paragraph seems
> to completely negate the assertion that the code has been running w/ OW
> owing to /SAVE and its initialization (which is one-time only).

I'm a little confused as well, but a possibility does occur to me. It
could be that the code runs ok now with zero-init+save because each
subroutine where this applies is called only once, but that it would
need zeroing on each entry if the code ended up being called multiple
times.

Just a guess as to what might be meant. I have run into situations like
that in the past, where a code was once a standalone program, but then
gets converted to run in a loop or otherwise do multiple cases. It can
be a pain if the original code assumed zero initialization. Been there.
Done that.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

>> I do not disagree with that statement.  That is why I think that the explicit
>> zeroing of our local variables will be better for the code as that initial value
>> of zero in each subroutine call will be much more consistent with the
>> resultant calculations.
>
> I'm truly confused now about what you think is the right answer...and how you know whether the answer is, in fact, correct.

Because in my engineering judgement, the answers make sense.  Once one
gets the answers, they are fairly easy to work out what is reasonable and
what is not.  In a flash separator, vapor goes out the top and liquid goes out
the bottom.

> It makes no sense to me as the 2nd sentence of the first paragraph seems to completely negate the assertion that the code has been 
> running w/ OW owing to /SAVE and its initialization (which is one-time only).

Me too.  I do not understand why the code is working either.  I could hazard
several theories but at the end of the day, the code is working with the /save
compiler option.

Thanks,
Lynn

Lynn McGuire wrote:
....

> That is not the behavior that I am seeing when the /save is dropped from
> OW 1.9.  I see that the y variable has a totally random, but consistent,
> value upon usage.  I see that you are using Watcom 11.0, not OW 1.9.
> 
> C:\dii>wfl386 /quiet wat.for
> 
> C:\dii>wat
>   6.0233654E+036
>   6.0233654E+036
....

Hmmm....which OS is that on?

That's interesting behavior, indeed.

I was unaware that there had actually been any changes in OW Fortran 
since the spin-off.  I knew folks had done some work on the C compiler 
but was unaware of anything on the Fortran side that would change such 
behavior.

If I weren't limited to slow dial-up I'd be tempted to download OW and 
check here but it would take days so isn't feasible.  I'll certainly 
know to keep the V11 compiler CDs for our performance monitoring code if 
it were ever needed to go back to the Watcom build at some future point 
(say if OS/2 comes back again, say... :) altho there are still at least 
a dozen of the workstations still running 24/7 at a couple of the plants 
last I knew but all the rest are on NT4 (!!!)  or newer (altho I'm sure 
XP is latest for these).

Anyway, glad it's your problem and not mine even though it an 
interesting dilemma...

Good luck...

Oh...You don't have the defunct commercial Watcom compiler, too, 
perchance, do you by any stroke of luck?

--

Lynn McGuire wrote:
....

> Me too.  I do not understand why the code is working either.  I could hazard
> several theories but at the end of the day, the code is working with the /save
> compiler option.
....

Oh, something just came to me...the statement that in particular you 
initialized the array indices.  W/O that and /NOSAVE were you getting 
floating point errors on the integer conversion, perhaps?

That I could see if it simply crashed owing to random memory given the 
other result that OW does different on clearing process memory as 
compared to Watcom which I've been used to (altho I had assumed it was 
OS spawning process security behavior rather than the compiler having 
not investigated where it actually was happening).

--

> Hmmm....which OS is that on?

Windows XP Pro x86.

> I was unaware that there had actually been any changes in OW Fortran since the spin-off.  I knew folks had done some work on the C 
> compiler but was unaware of anything on the Fortran side that would change such behavior.

The code generator has had a massive amount of work over the years.  Since
the C, C++ and F77 compilers feed directly to it, any change in the code
generator for a C or C++ problem automatically affects the F77 compiler.  I
have had to have them fix a code generator change or two over the years for
being too aggressive:  http://openwatcom.org/index.php/C_Compilers_Release_Changes

> If I weren't limited to slow dial-up I'd be tempted to download OW and check here but it would take days so isn't feasible.  I'll 
> certainly know to keep the V11 compiler CDs for our performance monitoring code if it were ever needed to go back to the Watcom 
> build at some future point (say if OS/2 comes back again, say... :) altho there are still at least a dozen of the workstations 
> still running 24/7 at a couple of the plants last I knew but all the rest are on NT4 (!!!)  or newer (altho I'm sure XP is latest 
> for these).

The current OW still supports OS/2, DOS16 and DOS32 apps along with
Win32 and linux apps (a work in progress).  There is actually some one
writing a F2003 code parser to go directly to the OW code generator.

> Oh...You don't have the defunct commercial Watcom compiler, too, perchance, do you by any stroke of luck?

I have Watcom versions 8.0 through 11.0 at the office.  Somewhere.

Lynn

> Oh, something just came to me...the statement that in particular you initialized the array indices.  W/O that and /NOSAVE were you 
> getting floating point errors on the integer conversion, perhaps?

Nope.  The integer variables that were used to build the array indices
had random values in them.  Generally huge random numbers that caused
the program to crash immediately when that code was hit.  One of them was:

            NOUT = IVDY(NWOUT).I
            IF (NOUT .GT. MAXOUT) MAXOUT = NOUT

where the maxout initialization code was jumped over so it had a random
value of something like 101,456,999 and nout was equal to 1, 2 or 3.  I
put a maxout=0 at the beginning of the subroutine and all was OK.

> That I could see if it simply crashed owing to random memory given the other result that OW does different on clearing process 
> memory as compared to Watcom which I've been used to (altho I had assumed it was OS spawning process security behavior rather than 
> the compiler having not investigated where it actually was happening).

The code generator symbol table organizer was rewritten several years ago
in version 1.5 or 1.6.  And the F77 symbol library was made case sensitive
like C code is so I expect that may have changed then.  Or not, it is tough
to tell without testing each version.

BTW, I am one of the code maintainers for OW also.  I griped too much
about a code parser/generator bug and they gave a login to fix it myself.  I
have made a few changes in the F77 run time library with extreme hand
holding by the lead code maintainer.  Since OW is over 2,000,000 lines of
C code, any changes are nerve wracking at best.

Thanks,
Lynn

Lynn McGuire wrote:
>> Oh, something just came to me...the statement that in particular
>> you initialized the array indices. W/O that and /NOSAVE were you
>> getting floating point errors on the integer conversion, perhaps? >
> Nope.  The integer variables that were used to build the array indices
> had random values in them.  Generally huge random numbers that caused
> the program to crash immediately when that code was hit.  One of them was:
> 
>             NOUT = IVDY(NWOUT).I
>             IF (NOUT .GT. MAXOUT) MAXOUT = NOUT
> 
> where the maxout initialization code was jumped over so it had a random
> value of something like 101,456,999 and nout was equal to 1, 2 or 3.  I
> put a maxout=0 at the beginning of the subroutine and all was OK.
....

That's the kind of thing I was thinking about; just badly written...

I think the option others have suggested of alternate compilers to 
produce warnings on at least some of these items would be beneficial in 
the process rather than relying on the crashes to find them.

--

> Hmmm....which OS is that on?

One Windows 7 Ultimate x64 using Watcom 11.0c I get:

C:\temp>wfl386 wat.for
Watcom F77/32 Compile and Link Utility Version 11.0c
Copyright by Sybase, Inc., and its subsidiaries, 1990, 2000.
All rights reserved.  Watcom is a trademark of Sybase, Inc.
         wfc386 wat.for
Watcom FORTRAN 77/32 Optimizing Compiler Version 11.0c  2010/07/06 14:21:37
Copyright by Sybase, Inc., and its subsidiaries, 1984, 2000.
All rights reserved.  Watcom is a trademark of Sybase, Inc.
wat.for: 10 statements, 67 bytes, 1 extensions, 0 warnings, 0 errors

WATCOM Linker Version 11.0c
Copyright by Sybase, Inc., and its subsidiaries, 1985, 2000.
All rights reserved.  Watcom is a trademark of Sybase, Inc.
loading object files
searching libraries
creating a Windows NT character-mode executable

C:\temp>wat
   1.0141403E+033
   1.0141403E+033

So the behavior of unsaved local variables has not changed
between Watcom 11.0c and OW 1.9.

Lynn

Lynn McGuire wrote:
....

> So the behavior of unsaved local variables has not changed
> between Watcom 11.0c and OW 1.9.


Interesting, I'll have to keep that in mind (altho hopefully I have no 
code that relies on the behavior difference I'll not bet terribly heavy 
on it altho had no issues w/ the CVF port).    :)

I guess I was asleep at the switch on V11 updates as things were pretty 
inactive on the monitoring stuff at about that time so afaik there 
aren't any updates around to compare to.

Anyway, sounds as though you're getting to be on your way...

--

> Interesting, I'll have to keep that in mind (altho hopefully I have no code that relies on the behavior difference I'll not bet
> terribly heavy on it altho had no issues w/ the CVF port). :)

> Anyway, sounds as though you're getting to be on your way...

Back at work so working on the excel ole automation interface
again.  This crap makes smalltalk look easy !

Lynn

Lynn McGuire wrote:
....

> ... makes smalltalk look easy !

oooh...there's a reminder of a past there!  :)

--

> That's the kind of thing I was thinking about; just badly written...
>
> I think the option others have suggested of alternate compilers to produce warnings on at least some of these items would be 
> beneficial in the process rather than relying on the crashes to find them.

I was thinking of a perl script to go through and init all local variable
explicitely for all 5000 sibroutines. Kinda brute force but should get
the job done.

Thanks,
Lynn

Lynn McGuire wrote:
>> That's the kind of thing I was thinking about; just badly written...
>>
>> I think the option others have suggested of alternate compilers to produce warnings on at least some of these items would be 
>> beneficial in the process rather than relying on the crashes to find them.
> 
> I was thinking of a perl script to go through and init all local variable
> explicitely for all 5000 sibroutines. Kinda brute force but should get
> the job done.

If you're lucky and there really aren't any that actually do need their 
values retained between invocations.

--

On 7/10/2010 10:50 AM, Lynn McGuire wrote:
>> That's the kind of thing I was thinking about; just badly written...
>>
>> I think the option others have suggested of alternate compilers to produce warnings on at least some of these items would be
>> beneficial in the process rather than relying on the crashes to find them.
>
> I was thinking of a perl script to go through and init all local variable
> explicitely for all 5000 sibroutines. Kinda brute force but should get
> the job done.

You might want to include some automated testing.  Save the current 
output in a file, change one subroutine, recompile, rerun, diff the 
output with the original.  If it looks good, rinse and repeat with 
another subroutine, otherwise revert to the original subroutine source 
and move on to the next one.  Hopefully, you'll be left with n (where n 
<< 5000) subroutines which will need some editing by hand.

Louis

>> I was thinking of a perl script to go through and init all local variable
>> explicitely for all 5000 sibroutines. Kinda brute force but should get
>> the job done.
>
> You might want to include some automated testing.  Save the current output in a file, change one subroutine, recompile, rerun, 
> diff the output with the original.  If it looks good, rinse and repeat with another subroutine, otherwise revert to the original 
> subroutine source and move on to the next one.  Hopefully, you'll be left with n (where n << 5000) subroutines which will need 
> some editing by hand.

We have over 600 automated tests that we perform with our software
before we ship any full or patch releases.  When you write and sell
commercial software, it is a given.

Thanks,
Lynn

On 7/10/2010 2:34 PM, Lynn McGuire wrote:
>>> I was thinking of a perl script to go through and init all local variable
>>> explicitely for all 5000 sibroutines. Kinda brute force but should get
>>> the job done.
>>
>> You might want to include some automated testing.  Save the current output in a file, change one subroutine, recompile, rerun,
>> diff the output with the original.  If it looks good, rinse and repeat with another subroutine, otherwise revert to the original
>> subroutine source and move on to the next one.  Hopefully, you'll be left with n (where n<<  5000) subroutines which will need
>> some editing by hand.
>
> We have over 600 automated tests that we perform with our software
> before we ship any full or patch releases.  When you write and sell
> commercial software, it is a given.
>
> Thanks,
> Lynn
>
>

You'd be surprised (or maybe not) at what gets shipped untested.

Now you get to build some or all of those tests into an automated 
process to edit part of the source and retest.  You could get fancy and 
run complete tests only after editing every 100 subroutines or 
something.  Once you get it set up, you could start it just before you 
go home for the day (or weekend) and let it do its thing...

Louis

> You'd be surprised (or maybe not) at what gets shipped untested.

Not really.  I've seen a lot in the commercial software arena.

> Now you get to build some or all of those tests into an automated process to edit part of the source and retest. You could get fancy
> and run complete tests only after editing every 100 subroutines or something. Once you get it set up, you could start it just before
> you go home for the day (or weekend) and let it do its thing...

It takes 72 hours to run our tests now.  If nothing goes wrong.
And something almost always goes wrong <g>.

Lynn