Is there a way in Fortran to designate an integer value as integer*8 ?

[Lynn McGuire]

I need many of my integers to be integer*8 in my port to 64 bit. In
C/C++ code, I can say 123456L to mean a long long value, generally 64
bit. Is there a corresponding way to do this in Fortran or am I stuck with:

call xyz (1)

subroutine xyz (ivalue)
integer*8 ivalue
...
return end

must be:

integer*8 ivalue
...
ivalue = 1
call xyz (ivalue)

Thanks,
Lynn

[Lawrence D'Oliveiro]

On Tue, 1 Oct 2024 21:58:40 -0500, Lynn McGuire wrote:

> I need many of my integers to be integer*8 in my port to 64 bit. In
> C/C++ code, I can say 123456L to mean a long long value, generally 64
> bit. Is there a corresponding way to do this in Fortran ...

integer(kind = 8), parameter :: bigval = 9223372036854775807_8
print *, bigval

prints

9223372036854775807

[Lynn McGuire]

On 10/2/2024 2:00 AM, Lawrence D'Oliveiro wrote:
> On Tue, 1 Oct 2024 21:58:40 -0500, Lynn McGuire wrote:
>
>> I need many of my integers to be integer*8 in my port to 64 bit. In
>> C/C++ code, I can say 123456L to mean a long long value, generally 64
>> bit. Is there a corresponding way to do this in Fortran ...
>
> integer(kind = 8), parameter :: bigval = 9223372036854775807_8
> print *, bigval
>
> prints
>
> 9223372036854775807

Thanks !

I was afraid of that. I will have to put _8 in about 100,000 lines of
my F77 code. And the future conversion to C++ will need special handling.

Lynn

[Lawrence D'Oliveiro]

On Wed, 2 Oct 2024 14:30:48 -0500, Lynn McGuire wrote:

> I will have to put _8 in about 100,000 lines of
> my F77 code.

There is another way: have a look at the -fdefault-integer-8 and
-finteger-4-integer-8 options
<https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gfortran/Fortran-Dialect-Options.html>.

[Lynn McGuire]

On 10/2/2024 5:07 PM, Lawrence D'Oliveiro wrote:
> On Wed, 2 Oct 2024 14:30:48 -0500, Lynn McGuire wrote:
>
>> I will have to put _8 in about 100,000 lines of
>> my F77 code.
>
> There is another way: have a look at the -fdefault-integer-8 and
> -finteger-4-integer-8 options
> <https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gfortran/Fortran-Dialect-Options.html>.

And we have a winner ! Worked like a champ in Simply Fortran.

Lynn

[Steven G. Kargl]

On Wed, 02 Oct 2024 14:30:48 -0500, Lynn McGuire wrote:

> On 10/2/2024 2:00 AM, Lawrence D'Oliveiro wrote:
>> On Tue, 1 Oct 2024 21:58:40 -0500, Lynn McGuire wrote:
>>
>>> I need many of my integers to be integer*8 in my port to 64 bit. In
>>> C/C++ code, I can say 123456L to mean a long long value, generally 64
>>> bit. Is there a corresponding way to do this in Fortran ...
>>
>> integer(kind = 8), parameter :: bigval = 9223372036854775807_8
>> print *, bigval
>>
>> prints
>>
>> 9223372036854775807
>
> Thanks !
>
> I was afraid of that. I will have to put _8 in about 100,000 lines of
> my F77 code. And the future conversion to C++ will need special handling.
>

If you 100,000 lines of C++ without a trailing 'L', you would
need to add 'L' to get a long int. You also only need to add
'_8' (or 'L') to those values that would exceed huge(1) in
magnitude as integer*4 is a proper subset of integer*8 and
Fortran does conversion when required.

--
steve

[Lynn McGuire]

On 10/2/2024 11:27 PM, Steven G. Kargl wrote:
> On Wed, 02 Oct 2024 14:30:48 -0500, Lynn McGuire wrote:
>
>> On 10/2/2024 2:00 AM, Lawrence D'Oliveiro wrote:
>>> On Tue, 1 Oct 2024 21:58:40 -0500, Lynn McGuire wrote:
>>>
>>>> I need many of my integers to be integer*8 in my port to 64 bit. In
>>>> C/C++ code, I can say 123456L to mean a long long value, generally 64
>>>> bit. Is there a corresponding way to do this in Fortran ...
>>>
>>> integer(kind = 8), parameter :: bigval = 9223372036854775807_8
>>> print *, bigval
>>>
>>> prints
>>>
>>> 9223372036854775807
>>
>> Thanks !
>>
>> I was afraid of that. I will have to put _8 in about 100,000 lines of
>> my F77 code. And the future conversion to C++ will need special handling.
>>
>
> If you 100,000 lines of C++ without a trailing 'L', you would
> need to add 'L' to get a long int. You also only need to add
> '_8' (or 'L') to those values that would exceed huge(1) in
> magnitude as integer*4 is a proper subset of integer*8 and
> Fortran does conversion when required.

If Fortran does an automatic conversion from I*4 to I*8, why does the
compiler gripe at me that the integer constant does not match the
subroutine argument type ?

Thanks,
Lynn

[Steven G. Kargl]

On Thu, 03 Oct 2024 02:06:28 -0500, Lynn McGuire wrote:

> On 10/2/2024 11:27 PM, Steven G. Kargl wrote:
>> On Wed, 02 Oct 2024 14:30:48 -0500, Lynn McGuire wrote:
>>
>>> On 10/2/2024 2:00 AM, Lawrence D'Oliveiro wrote:
>>>> On Tue, 1 Oct 2024 21:58:40 -0500, Lynn McGuire wrote:
>>>>
>>>>> I need many of my integers to be integer*8 in my port to 64 bit. In
>>>>> C/C++ code, I can say 123456L to mean a long long value, generally 64
>>>>> bit. Is there a corresponding way to do this in Fortran ...
>>>>
>>>> integer(kind = 8), parameter :: bigval = 9223372036854775807_8
>>>> print *, bigval
>>>>
>>>> prints
>>>>
>>>> 9223372036854775807
>>>
>>> Thanks !
>>>
>>> I was afraid of that. I will have to put _8 in about 100,000 lines of
>>> my F77 code. And the future conversion to C++ will need special handling.
>>>
>>
>> If you 100,000 lines of C++ without a trailing 'L', you would
>> need to add 'L' to get a long int. You also only need to add
>> '_8' (or 'L') to those values that would exceed huge(1) in
>> magnitude as integer*4 is a proper subset of integer*8 and
>> Fortran does conversion when required.
>
> If Fortran does an automatic conversion from I*4 to I*8, why does the
> compiler gripe at me that the integer constant does not match the
> subroutine argument type ?

Well, to begin, you were talking about numeric literal constants.
I doubt you add '_8' (or 'L') to all entities declared as 'integer*4'
(or long int).

integer*8 i ! 42 is integer*4 and automatically converted to integer*8
i = 42 ! on assignment.
i = 3_8 * 2 ! Mixed-mode math. 2 is magically converted to integer*8

The compiler is not complaining. It is informing you of an mismatch
between an actual argument and the dummy argument. If one is 'integer*4'
and the other 'integer*8', you have 32 undefined bits.

As the person who gave gfortran the -fdefault-integer-8 option, I hope
your XXX kloc of code uses neither equivalence nor common blocks.

--
steve

[Lynn McGuire]

On 10/3/2024 10:02 AM, Steven G. Kargl wrote:
> On Thu, 03 Oct 2024 02:06:28 -0500, Lynn McGuire wrote:
>
>> On 10/2/2024 11:27 PM, Steven G. Kargl wrote:
>>> On Wed, 02 Oct 2024 14:30:48 -0500, Lynn McGuire wrote:
>>>
>>>> On 10/2/2024 2:00 AM, Lawrence D'Oliveiro wrote:
>>>>> On Tue, 1 Oct 2024 21:58:40 -0500, Lynn McGuire wrote:
>>>>>
>>>>>> I need many of my integers to be integer*8 in my port to 64 bit. In
>>>>>> C/C++ code, I can say 123456L to mean a long long value, generally 64
>>>>>> bit. Is there a corresponding way to do this in Fortran ...
>>>>>
>>>>> integer(kind = 8), parameter :: bigval = 9223372036854775807_8
>>>>> print *, bigval
>>>>>
>>>>> prints
>>>>>
>>>>> 9223372036854775807
>>>>
>>>> Thanks !
>>>>
>>>> I was afraid of that. I will have to put _8 in about 100,000 lines of
>>>> my F77 code. And the future conversion to C++ will need special handling.
>>>>
>>>
>>> If you 100,000 lines of C++ without a trailing 'L', you would
>>> need to add 'L' to get a long int. You also only need to add
>>> '_8' (or 'L') to those values that would exceed huge(1) in
>>> magnitude as integer*4 is a proper subset of integer*8 and
>>> Fortran does conversion when required.
>>
>> If Fortran does an automatic conversion from I*4 to I*8, why does the
>> compiler gripe at me that the integer constant does not match the
>> subroutine argument type ?
>
> Well, to begin, you were talking about numeric literal constants.
> I doubt you add '_8' (or 'L') to all entities declared as 'integer*4'
> (or long int).
>
> integer*8 i ! 42 is integer*4 and automatically converted to integer*8
> i = 42 ! on assignment.
> i = 3_8 * 2 ! Mixed-mode math. 2 is magically converted to integer*8
>
> The compiler is not complaining. It is informing you of an mismatch
> between an actual argument and the dummy argument. If one is 'integer*4'
> and the other 'integer*8', you have 32 undefined bits.
>
> As the person who gave gfortran the -fdefault-integer-8 option, I hope
> your XXX kloc of code uses neither equivalence nor common blocks.

I have 197 common blocks included from dedicated files and a massive
number of equivalences all over the place. Several of the equivalences
are actually in the common block files. The equivalences have made the
eventual C++ conversion of the Fortran code tricky.

This code is 850,000 lines of F77 code and 50,000 lines of C++ code that
dates back to 1965 or so. Half of the code is Fortran IV and half is
F77. It has been ported to 12 ? different platforms, mostly mainframes
in the 1960s, 1970s, 1980s, and 1990s.

Lynn

[Steven G. Kargl]

On Thu, 03 Oct 2024 14:32:28 -0500, Lynn McGuire wrote:

> On 10/3/2024 10:02 AM, Steven G. Kargl wrote:
>> On Thu, 03 Oct 2024 02:06:28 -0500, Lynn McGuire wrote:
>>
>>> On 10/2/2024 11:27 PM, Steven G. Kargl wrote:
>>>
>> As the person who gave gfortran the -fdefault-integer-8 option, I hope
>> your XXX kloc of code uses neither equivalence nor common blocks.
>
> I have 197 common blocks included from dedicated files and a massive
> number of equivalences all over the place. Several of the equivalences
> are actually in the common block files. The equivalences have made the
> eventual C++ conversion of the Fortran code tricky.
>
> This code is 850,000 lines of F77 code and 50,000 lines of C++ code that
> dates back to 1965 or so. Half of the code is Fortran IV and half is
> F77. It has been ported to 12 ? different platforms, mostly mainframes
> in the 1960s, 1970s, 1980s, and 1990s.


The gfortran's -fdefault-* options break storage association.
This may have some interesting alignment issues, which can
lead to hard to find bugs. If you think to needed the
-fdefault-integer-8 option, then I'll kindly suggest that you
likely want to use -finteger-4-integer-8 option instead.

My personal recommendation would be to do a proper porting from
integer (aka integer*4) to integer(kind=8). And, yes, 8 in the
'kind=8' is not portable.

--
steve

[Clive Page]

On 03/10/2024 20:59, Steven G. Kargl wrote:
> My personal recommendation would be to do a proper porting from
> integer (aka integer*4) to integer(kind=8). And, yes, 8 in the
> 'kind=8' is not portable.
>

Yes because different compilers use different integer kind numbers for different purposes: at least one uses kinds 1, 2, 3, 4 for the four most common numbers of bytes where other compilers use 1, 2, 4, 8. But if you use integer(kind=int64) this is portable.

--
Clive Page

[Steven G. Kargl]

On Thu, 03 Oct 2024 22:28:31 +0100, Clive Page wrote:

> On 03/10/2024 20:59, Steven G. Kargl wrote:
>> My personal recommendation would be to do a proper porting from
>> integer (aka integer*4) to integer(kind=8). And, yes, 8 in the
>> 'kind=8' is not portable.
>>
>
> Yes because different compilers use different integer kind numbers for
different purposes: at least one uses kinds 1, 2, 3, 4 for the four most
common numbers of bytes where other compilers use 1, 2, 4, 8. But if you
use integer(kind=int64) this is portable.

(Although unlikely) what happens when int64 = -1?
I suppose 'integer(-1)' is portable to the extent
that a compiler will error out.

--
steve

[Lawrence D'Oliveiro]

On Thu, 3 Oct 2024 14:32:28 -0500, Lynn McGuire wrote:

> I have 197 common blocks included from dedicated files and a massive
> number of equivalences all over the place.

Try getting rid of at least some of them, by using “contains”.

[Lynn McGuire]

On 10/3/2024 5:08 PM, Lawrence D'Oliveiro wrote:
> On Thu, 3 Oct 2024 14:32:28 -0500, Lynn McGuire wrote:
>
>> I have 197 common blocks included from dedicated files and a massive
>> number of equivalences all over the place.
>
> Try getting rid of at least some of them, by using “contains”.

What does "contains" do ? My knowledge of Fortran stopped at F77+.

Lynn

[Lawrence D'Oliveiro]

On Thu, 3 Oct 2024 17:13:40 -0500, Lynn McGuire wrote:

> On 10/3/2024 5:08 PM, Lawrence D'Oliveiro wrote:
>>
>> On Thu, 3 Oct 2024 14:32:28 -0500, Lynn McGuire wrote:
>>
>>> I have 197 common blocks included from dedicated files and a massive
>>> number of equivalences all over the place.
>>
>> Try getting rid of at least some of them, by using “contains”.
>
> What does "contains" do ? My knowledge of Fortran stopped at F77+.

Pick up a Fortran-90-or-later spec. This is not your father’s Fortran any
more. “contains” lets you put subroutines and functions directly in the
main program, so they can refer directly to program globals instead of
having to go through “common” blocks.

I posted an example of modernized Fortran code right here a few months
ago, and I see there’s a comment from you on it, so you must have seen it.

[Lynn McGuire]

On 10/3/2024 5:34 PM, Lawrence D'Oliveiro wrote:
> On Thu, 3 Oct 2024 17:13:40 -0500, Lynn McGuire wrote:
>
>> On 10/3/2024 5:08 PM, Lawrence D'Oliveiro wrote:
>>>
>>> On Thu, 3 Oct 2024 14:32:28 -0500, Lynn McGuire wrote:
>>>
>>>> I have 197 common blocks included from dedicated files and a massive
>>>> number of equivalences all over the place.
>>>
>>> Try getting rid of at least some of them, by using “contains”.
>>
>> What does "contains" do ? My knowledge of Fortran stopped at F77+.
>
> Pick up a Fortran-90-or-later spec. This is not your father’s Fortran any
> more. “contains” lets you put subroutines and functions directly in the
> main program, so they can refer directly to program globals instead of
> having to go through “common” blocks.
>
> I posted an example of modernized Fortran code right here a few months
> ago, and I see there’s a comment from you on it, so you must have seen it.

I started writing Fortran IV in 1975. Been down a lot of roads since
then. I've written software in Fortran IV and 77, Pascal, C, C++, Curl,
etc. They are all running together now, I am getting old.

Lynn

[Lawrence D'Oliveiro]

On Thu, 3 Oct 2024 23:44:24 -0500, Lynn McGuire wrote:

> I started writing Fortran IV in 1975. Been down a lot of roads since
> then. I've written software in Fortran IV and 77, Pascal, C, C++, Curl,
> etc. They are all running together now, I am getting old.

You mean “Perl” (the language) instead of “Curl” (which is just a download
tool)?

No Lisp-type languages? Some of them can do your head in. Assembler? SQL?
POSIX shells? JavaScript? My favourite, Python?

Some cool stuff in modern Fortran: free-form layout, with no more column
numbers! Format strings can come from expressions within the I/O
statement, so there is no more need for statement numbers at all. Types
can have a limited form of parameterization, even allowing for function
overloading. There are structured types, even object orientation.

[Lynn McGuire]

On 10/4/2024 12:46 AM, Lawrence D'Oliveiro wrote:
> On Thu, 3 Oct 2024 23:44:24 -0500, Lynn McGuire wrote:
>
>> I started writing Fortran IV in 1975. Been down a lot of roads since
>> then. I've written software in Fortran IV and 77, Pascal, C, C++, Curl,
>> etc. They are all running together now, I am getting old.
>
> You mean “Perl” (the language) instead of “Curl” (which is just a download
> tool)?
>
> No Lisp-type languages? Some of them can do your head in. Assembler? SQL?
> POSIX shells? JavaScript? My favourite, Python?
>
> Some cool stuff in modern Fortran: free-form layout, with no more column
> numbers! Format strings can come from expressions within the I/O
> statement, so there is no more need for statement numbers at all. Types
> can have a limited form of parameterization, even allowing for function
> overloading. There are structured types, even object orientation.

Yup, Perl, not Curl. AutoLisp. IBM 370 Assembly. Java. Basic. Lots
of shell language.

Yes, I am porting from Open Watcom C++ and F77 to Simply Fortran C++ and
GFortran right now. Lots of new stuff that I won't use. Incredibly
better error detection, especially on variable types and bounds.

Lynn

[Lawrence D'Oliveiro]

On Fri, 4 Oct 2024 23:10:29 -0500, Lynn McGuire wrote:

> Yup, Perl, not Curl. AutoLisp.

Poor you. The idiosyncratic syntax of Lisp without the redeeming advanced
features.

> Yes, I am porting from Open Watcom C++ and F77 to Simply Fortran C++ and
> GFortran right now. Lots of new stuff that I won't use. Incredibly
> better error detection, especially on variable types and bounds.

If I were you, I would look for opportunities to simplify things in that
Fortran code by using new features, where I have to make major
modifications to those parts anyway.

[Lynn McGuire]

On 10/5/2024 1:39 AM, Lawrence D'Oliveiro wrote:
> On Fri, 4 Oct 2024 23:10:29 -0500, Lynn McGuire wrote:
>
>> Yup, Perl, not Curl. AutoLisp.
>
> Poor you. The idiosyncratic syntax of Lisp without the redeeming advanced
> features.
>
>> Yes, I am porting from Open Watcom C++ and F77 to Simply Fortran C++ and
>> GFortran right now. Lots of new stuff that I won't use. Incredibly
>> better error detection, especially on variable types and bounds.
>
> If I were you, I would look for opportunities to simplify things in that
> Fortran code by using new features, where I have to make major
> modifications to those parts anyway.

All of the modifications that I am making are minor. Mostly changing my
old 8 byte data structure/union to I*8 and L*8.

Lynn

[Lawrence D'Oliveiro]

On Sat, 5 Oct 2024 15:04:38 -0500, Lynn McGuire wrote:

> On 10/5/2024 1:39 AM, Lawrence D'Oliveiro wrote:
>>
>> If I were you, I would look for opportunities to simplify things in
>> that Fortran code by using new features, where I have to make major
>> modifications to those parts anyway.
>
> All of the modifications that I am making are minor. Mostly changing my
> old 8 byte data structure/union to I*8 and L*8.

Here’s another useful thing to do: get rid of COMMON blocks and replace
them with MODULE «name» ... USE «name».

As the compiler does its checking, you may pick up a few long-unnoticed
typos along the way ...

[Lynn McGuire]

On 10/20/2024 12:38 AM, Lawrence D'Oliveiro wrote:
> On Sat, 5 Oct 2024 15:04:38 -0500, Lynn McGuire wrote:
>
>> On 10/5/2024 1:39 AM, Lawrence D'Oliveiro wrote:
>>>
>>> If I were you, I would look for opportunities to simplify things in
>>> that Fortran code by using new features, where I have to make major
>>> modifications to those parts anyway.
>>
>> All of the modifications that I am making are minor. Mostly changing my
>> old 8 byte data structure/union to I*8 and L*8.
>
> Here’s another useful thing to do: get rid of COMMON blocks and replace
> them with MODULE «name» ... USE «name».
>
> As the compiler does its checking, you may pick up a few long-unnoticed
> typos along the way ...

I include all of my common blocks as files to stop typos.

Lynn

[Thomas Koenig]

Lynn McGuire <***@gmail.com> schrieb:

> I include all of my common blocks as files to stop typos.

That is surely an old technique, but only really works to 100%
if you adhere to some additional style constraints in your code.

Consider

foo.f:

DIMENSION A(10)
INCLUDE "common.inc"

bar.f:

INCLUDE "common.inc"

(without the DIMENSION)

common.inc:

COMMON /COMMON/ A

[Lynn McGuire]

On 10/21/2024 12:41 AM, Thomas Koenig wrote:
> Lynn McGuire <***@gmail.com> schrieb:
>
>> I include all of my common blocks as files to stop typos.
>
> That is surely an old technique, but only really works to 100%
> if you adhere to some additional style constraints in your code.
>
> Consider
>
> foo.f:
>
> DIMENSION A(10)
> INCLUDE "common.inc"
>
> bar.f:
>
> INCLUDE "common.inc"
>
> (without the DIMENSION)
>
> common.inc:
>
> COMMON /COMMON/ A

Here is one of my 197 common block include files, global.inc:

C global.inc
C
C
C 11/21/19 Lynn McGuire pmr 6299, add new ncp max used variable for
chemtran
C 11/14/19 CPO PMR 6299 - Add global_aqueous_keyk
C 07/05/19 Lynn McGuire pmr 6036, add do not call solid isothermal flash
C 08/08/18 Lynn McGuire pmr 6308, add spreadsheet unit module
C 08/24/17 Lynn McGuire add max lkey constant
C 03/15/17 Lynn McGuire pmr 6265, add stream print around unit module
calls
C 03/18/15 Lynn McGuire add next simulation time
C 09/30/14 CPO PMR 6090 - Add num_crude_streams
C 08/15/14 Lynn McGuire add max line segments parameter
C 07/18/14 Lynn McGuire move oneline to dii.inc
C 03/10/14 Lynn McGuire add new thermo failure logical
C 08/01/12 Lynn McGuire add stream specs to the common area
C 12/06/11 Lynn McGuire remove max_kvalue_methods
C 01/07/11 Lynn McGuire increase max equips to 56 for tank and add
time variables
C 10/14/10 CPO Added logicals do_not_call_liqh, do_not_call_vaph.
C 10/05/10 CPO Added logicals do_not_call_threephs and do_not_call_flai.
C 12/29/09 CPO PMR 5486 - Added logical lrespect_user_pitch.
C 11/10/09 CPO Moved ne_did_not_converge and equipment_fail_count from
C global.inc to here so that we can use max_nodes to
C size the ne_did_not_converge array.
C 06/29/09 Michael McGuire removed SUBGL*
C 04/17/09 Lynn McGuire add new logicals for telling us when to use and
C when not to use lnolimit
C 11/20/08 Lynn McGuire add oneline
C 11/07/08 Lynn McGuire add max_kvalue_methods
C 08/11/08 Lynn McGuire add max_components and max_nodes
C 07/17/08 Colin Sturm PMR 4920 - increased max_equip_types (+1) to 55
C to make room for new equipment module steam
ejector
C 07/17/08 Colin Sturm PMR 4213 - increased max_equip_types (+1) to 54
C to make room for new equipment module packed
column
C 12/19/07 GDF Added LNOLIMIT which turns off ADBF initial limit tests
C for refine in FDATA, which calls ADBF.
C 07/23/07 Lynn McGuire change tblbnm to char*4
C 08/04/06 Lynn McGuire add max_equip_types
C 07/31/06 Binh Declared IDCOMSKD as integer
C 07/24/06 Binh Declared max_ncp as integer
C 09/24/04 Lynn McGuire cut global into two common blocks to get rid
of alignment errors
C 03 Feb 04 GDF Added IDCOMSKD to common so available in LNCODE (set
IDKINT)
C 22-Mar-89 W. E. Hensley, Jr. (PMR 2498)
C Equivalenced TBLBNM to NERZZZ for 386 DOS security code.
C 07/30/96 Lynn McGuire removed IFBL1, IFBL2, IFBL3 from here
C and from MKBL.F, AMOCO.F, EQUIP.F
C 07/20/00 Lynn McGuire added max_ncp
C 04/11/02 Lynn McGuire add globalfilenames common block
C 11/01/02 Lynn McGuire add streamfilename



C ne_did_not_converge - set in scan.f, and used to indicate failure of
unit
C modules. There are a maximum of max_nodes unit
C modules allowed in DesignII.
C equipment_fail_count - the number of equipment modules that have failed.
C thermo_init_failed - true if thermo_init_failed and should stop
calculations
C print_streams_for_each_unit - print curent inlet and outlet stream
conditions
C before and after each unit module call
C max_lkey - this is for the LKEY bank size


integer MAX_NCP
PARAMETER (MAX_NCP = 1000)

integer max_equip_types
parameter (max_equip_types = 57)

integer max_components
parameter (max_components = 9999)

integer max_nodes
parameter (max_nodes = 9999)

integer max_lkey
parameter (max_lkey = 32)

C aqueous phase thermo kvalue, used in flai, adbf, and threephs
C 20 is apisou, the current number
integer global_aqueous_keyk
parameter (global_aqueous_keyk = 20)



COMMON / GLOBAL / KTRACE, NCP, SETSTP, NDYNER, NERQQQ, LNOLIMIT,
* do_not_call_pivf, do_not_call_adbf,
* ne_did_not_converge, equipment_fail_count,
* lrespect_user_pitch, do_not_call_threephs,
* do_not_call_flai, do_not_call_liqh,
* do_not_call_vaph, thermo_init_failed,
* num_crude_streams, print_streams_for_each_unit,
* do_not_call_solid_isothermal_flash,
* ncp_max_used

integer KTRACE
integer NCP
logical SETSTP
integer NDYNER
integer NERQQQ
integer num_crude_streams
logical LNOLIMIT
logical do_not_call_pivf
logical do_not_call_adbf
logical lrespect_user_pitch
logical do_not_call_threephs
logical do_not_call_flai
logical do_not_call_liqh
logical do_not_call_vaph
logical thermo_init_failed
logical print_streams_for_each_unit
logical do_not_call_solid_isothermal_flash
C this is to record the ncp max used for chemtran since it
changes ncp on the fly
integer ncp_max_used




COMMON / GLOBAL1 / TBLBNM, IDCOMSKD

character*4 TBLBNM
integer IDCOMSKD

integer ne_did_not_converge (max_nodes)
integer equipment_fail_count





COMMON / GlobalFilenames / ChemTranDataFile, StreamDataFile,
1 RefineRestartFile

Character*1024 ChemTranDataFile
Character*1024 StreamDataFile
Character*1024 RefineRestartFile





common / globalTimeSettings / current_simulation_time,
* maximum_simulation_time,
* simulation_time_step,
* last_simulation_time,
* next_simulation_time

C current time in hours
double precision current_simulation_time
C the last current time in hours
double precision last_simulation_time
C maxium time in hours
double precision maximum_simulation_time
C time step in hours
double precision simulation_time_step
C the next time step in hours
double precision next_simulation_time





common / feed_stream_specs /
* num_saturate_feed_streams, feed_streams_to_saturate,
* num_print_summary_streams, print_summary_streams,
* num_print_ionic_streams, print_ionic_streams

integer num_saturate_feed_streams
integer feed_streams_to_saturate (max_nodes)
integer num_print_summary_streams
integer print_summary_streams (max_nodes)
integer num_print_ionic_streams
integer print_ionic_streams (max_nodes)

integer max_line_segments
parameter ( max_line_segments = 1000 )


Thanks,
Lynn

[Lawrence D'Oliveiro]

On Tue, 22 Oct 2024 00:07:41 -0500, Lynn McGuire wrote:

> Here is one of my 197 common block include files, global.inc:
>
> C global.inc
> C
> C
> C 11/21/19 Lynn McGuire pmr 6299, add new ncp max used variable for chemtran

Those are the sorts of things that belong in your version control
system.

> ...

What, no “implicit none”? Or do you put this in the including files?

> integer MAX_NCP
> PARAMETER (MAX_NCP = 1000)

All these pairs of lines can be replaced with single lines, e.g.

integer, parameter :: MAX_NCP = 1000

> COMMON / GLOBAL / KTRACE, NCP, SETSTP, NDYNER, NERQQQ, LNOLIMIT,
> * do_not_call_pivf, do_not_call_adbf,
> * ne_did_not_converge, equipment_fail_count,
> * lrespect_user_pitch, do_not_call_threephs,
> * do_not_call_flai, do_not_call_liqh,
> * do_not_call_vaph, thermo_init_failed,
> * num_crude_streams, print_streams_for_each_unit,
> * do_not_call_solid_isothermal_flash,
> * ncp_max_used
>
> integer KTRACE
> integer NCP
> logical SETSTP
> integer NDYNER
> integer NERQQQ
> integer num_crude_streams
> logical LNOLIMIT
> logical do_not_call_pivf
> logical do_not_call_adbf
> logical lrespect_user_pitch
> logical do_not_call_threephs
> logical do_not_call_flai
> logical do_not_call_liqh
> logical do_not_call_vaph
> logical thermo_init_failed
> logical print_streams_for_each_unit
> logical do_not_call_solid_isothermal_flash
> C this is to record the ncp max used for chemtran since itchanges ncp on the fly
> integer ncp_max_used

Much more concisely:

module GLOBAL
integer :: KTRACE, NCP, SETSTP, NDYNER, NERQQQ, num_crude_streams
logical :: LNOLIMIT, do_not_call_pivf, do_not_call_adbf, lrespect_user_pitch, &
do_not_call_threephs, do_not_call_flai, do_not_call_liqh, do_not_call_vaph, &
thermo_init_failed, print_streams_for_each_unit, do_not_call_solid_isothermal_flash
integer :: ncp_max_used
! this is to record the ncp max used for chemtran since itchanges ncp on the fly
end module GLOBAL

Then you just do “use GLOBAL” where you need these definitions.

etc etc

[Lynn McGuire]

On 10/22/2024 5:21 PM, Lawrence D'Oliveiro wrote:
> On Tue, 22 Oct 2024 00:07:41 -0500, Lynn McGuire wrote:
>
>> Here is one of my 197 common block include files, global.inc:
>>
>> C global.inc
>> C
>> C
>> C 11/21/19 Lynn McGuire pmr 6299, add new ncp max used variable for chemtran
>
> Those are the sorts of things that belong in your version control
> system.
>
>> ...
>
> What, no “implicit none”? Or do you put this in the including files?
>
>> integer MAX_NCP
>> PARAMETER (MAX_NCP = 1000)
>
> All these pairs of lines can be replaced with single lines, e.g.
>
> integer, parameter :: MAX_NCP = 1000
>
>> COMMON / GLOBAL / KTRACE, NCP, SETSTP, NDYNER, NERQQQ, LNOLIMIT,
>> * do_not_call_pivf, do_not_call_adbf,
>> * ne_did_not_converge, equipment_fail_count,
>> * lrespect_user_pitch, do_not_call_threephs,
>> * do_not_call_flai, do_not_call_liqh,
>> * do_not_call_vaph, thermo_init_failed,
>> * num_crude_streams, print_streams_for_each_unit,
>> * do_not_call_solid_isothermal_flash,
>> * ncp_max_used
>>
>> integer KTRACE
>> integer NCP
>> logical SETSTP
>> integer NDYNER
>> integer NERQQQ
>> integer num_crude_streams
>> logical LNOLIMIT
>> logical do_not_call_pivf
>> logical do_not_call_adbf
>> logical lrespect_user_pitch
>> logical do_not_call_threephs
>> logical do_not_call_flai
>> logical do_not_call_liqh
>> logical do_not_call_vaph
>> logical thermo_init_failed
>> logical print_streams_for_each_unit
>> logical do_not_call_solid_isothermal_flash
>> C this is to record the ncp max used for chemtran since itchanges ncp on the fly
>> integer ncp_max_used
>
> Much more concisely:
>
> module GLOBAL
> integer :: KTRACE, NCP, SETSTP, NDYNER, NERQQQ, num_crude_streams
> logical :: LNOLIMIT, do_not_call_pivf, do_not_call_adbf, lrespect_user_pitch, &
> do_not_call_threephs, do_not_call_flai, do_not_call_liqh, do_not_call_vaph, &
> thermo_init_failed, print_streams_for_each_unit, do_not_call_solid_isothermal_flash
> integer :: ncp_max_used
> ! this is to record the ncp max used for chemtran since itchanges ncp on the fly
> end module GLOBAL
>
> Then you just do “use GLOBAL” where you need these definitions.
>
> etc etc

I have "implicit none" in my first mandatory include for all 5,000+
subroutine files.

Lynn

[Lawrence D'Oliveiro]

On Tue, 22 Oct 2024 19:42:45 -0500, Lynn McGuire wrote:

> I have "implicit none" in my first mandatory include for all 5,000+
> subroutine files.

“gfortran -fimplicit-none” is also useful.

[Lynn McGuire]

On 10/22/2024 5:21 PM, Lawrence D'Oliveiro wrote:
> On Tue, 22 Oct 2024 00:07:41 -0500, Lynn McGuire wrote:
>
>> Here is one of my 197 common block include files, global.inc:
>>
>> C global.inc
>> C
>> C
>> C 11/21/19 Lynn McGuire pmr 6299, add new ncp max used variable for chemtran
>
> Those are the sorts of things that belong in your version control
> system.
>
>> ...
>
> What, no “implicit none”? Or do you put this in the including files?
>
>> integer MAX_NCP
>> PARAMETER (MAX_NCP = 1000)
>
> All these pairs of lines can be replaced with single lines, e.g.
>
> integer, parameter :: MAX_NCP = 1000
>
>> COMMON / GLOBAL / KTRACE, NCP, SETSTP, NDYNER, NERQQQ, LNOLIMIT,
>> * do_not_call_pivf, do_not_call_adbf,
>> * ne_did_not_converge, equipment_fail_count,
>> * lrespect_user_pitch, do_not_call_threephs,
>> * do_not_call_flai, do_not_call_liqh,
>> * do_not_call_vaph, thermo_init_failed,
>> * num_crude_streams, print_streams_for_each_unit,
>> * do_not_call_solid_isothermal_flash,
>> * ncp_max_used
>>
>> integer KTRACE
>> integer NCP
>> logical SETSTP
>> integer NDYNER
>> integer NERQQQ
>> integer num_crude_streams
>> logical LNOLIMIT
>> logical do_not_call_pivf
>> logical do_not_call_adbf
>> logical lrespect_user_pitch
>> logical do_not_call_threephs
>> logical do_not_call_flai
>> logical do_not_call_liqh
>> logical do_not_call_vaph
>> logical thermo_init_failed
>> logical print_streams_for_each_unit
>> logical do_not_call_solid_isothermal_flash
>> C this is to record the ncp max used for chemtran since itchanges ncp on the fly
>> integer ncp_max_used
>
> Much more concisely:
>
> module GLOBAL
> integer :: KTRACE, NCP, SETSTP, NDYNER, NERQQQ, num_crude_streams
> logical :: LNOLIMIT, do_not_call_pivf, do_not_call_adbf, lrespect_user_pitch, &
> do_not_call_threephs, do_not_call_flai, do_not_call_liqh, do_not_call_vaph, &
> thermo_init_failed, print_streams_for_each_unit, do_not_call_solid_isothermal_flash
> integer :: ncp_max_used
> ! this is to record the ncp max used for chemtran since itchanges ncp on the fly
> end module GLOBAL
>
> Then you just do “use GLOBAL” where you need these definitions.
>
> etc etc

BTW, my software dates before version control systems. 1965 or so to be
exact. And I like change notes in my code, it helps to figure out what
is going on. And some day we are going to change version control
systems again.

And I am not going to upgrade 850,000 lines of Fortran F77 code to F90
code just to have prettier code. I would still be here in 10 years
fixing all of the bugs from that disaster.

Lynn

[Lawrence D'Oliveiro]

On Wed, 23 Oct 2024 13:56:47 -0500, Lynn McGuire wrote:

> BTW, my software dates before version control systems.

Quite a bit of mine did, too, back in the day. Didn’t stop me from putting
them into version control. I even wrote some utility scripts to help with
the process <https://bitbucket.org/ldo17/fake_vcs/>.

> And I like change notes in my code, it helps to figure out what
> is going on.

You soon discover that version control history logs do all that, and more.
Remember, they show you, not just the comments you entered, but the actual
file diffs that go with them. Your current header comments cannot provide
that information.

Git also offers something you’re currently probably not doing because it’s
too difficult to do: branching and merging.

> And some day we are going to change version control systems again.

That will likely not be the difficult part. All the open-source VCSes
offer bulk import/export functions, to allow moving entire repos and
commit histories between them. Git offered plugins to allow easier
interoperation with other VCSes like Mercurial and SVN; any future
replacement for Git will have to do at least as well.

> And I am not going to upgrade 850,000 lines of Fortran F77 code to F90
> code just to have prettier code. I would still be here in 10 years
> fixing all of the bugs from that disaster.

Think about making it easier to maintain going forward.

[Lynn McGuire]

On 10/23/2024 3:53 PM, Lawrence D'Oliveiro wrote:
> On Wed, 23 Oct 2024 13:56:47 -0500, Lynn McGuire wrote:
>
>> BTW, my software dates before version control systems.
>
> Quite a bit of mine did, too, back in the day. Didn’t stop me from putting
> them into version control. I even wrote some utility scripts to help with
> the process <https://bitbucket.org/ldo17/fake_vcs/>.
>
>> And I like change notes in my code, it helps to figure out what
>> is going on.
>
> You soon discover that version control history logs do all that, and more.
> Remember, they show you, not just the comments you entered, but the actual
> file diffs that go with them. Your current header comments cannot provide
> that information.
>
> Git also offers something you’re currently probably not doing because it’s
> too difficult to do: branching and merging.
>
>> And some day we are going to change version control systems again.
>
> That will likely not be the difficult part. All the open-source VCSes
> offer bulk import/export functions, to allow moving entire repos and
> commit histories between them. Git offered plugins to allow easier
> interoperation with other VCSes like Mercurial and SVN; any future
> replacement for Git will have to do at least as well.
>
>> And I am not going to upgrade 850,000 lines of Fortran F77 code to F90
>> code just to have prettier code. I would still be here in 10 years
>> fixing all of the bugs from that disaster.
>
> Think about making it easier to maintain going forward.

I am going to change all the F77 code to C++ some day. I already have a
heavily modified version of F2C that I have rewritten extensively and
already moved several hundred subroutines from F77 to C++. The biggest
problem is the F77 write statements. F2C fixes the other big problem
automatically, the change of initial array index from one to zero.

Lynn

[Lawrence D'Oliveiro]

On Wed, 23 Oct 2024 16:47:13 -0500, Lynn McGuire wrote:

> I am going to change all the F77 code to C++ some day.

Assuming C++ stays in fashion long enough for you to finish the job ...

[Thomas Koenig]

Lynn McGuire <***@gmail.com> schrieb:

> I am going to change all the F77 code to C++ some day. I already have a
> heavily modified version of F2C that I have rewritten extensively and
> already moved several hundred subroutines from F77 to C++.

Modern Fortran might be the easier way, because a change can be done
incrementally, and this...

> The biggest
> problem is the F77 write statements.

... would not be an issue. What features is modern Fortran missing that
you need C++ for?

> F2C fixes the other big problem
> automatically, the change of initial array index from one to zero.

If I remember correctly, it does so by issueing invalid C (or
C++), by using negative offsets from pointers. Might work now,
might not work tomorrow.

But note the IIRC above.

[Lynn McGuire]

On 10/24/2024 1:28 AM, Thomas Koenig wrote:
> Lynn McGuire <***@gmail.com> schrieb:
>
>> I am going to change all the F77 code to C++ some day. I already have a
>> heavily modified version of F2C that I have rewritten extensively and
>> already moved several hundred subroutines from F77 to C++.
>
> Modern Fortran might be the easier way, because a change can be done
> incrementally, and this...
>
>> The biggest
>> problem is the F77 write statements.
>
> ... would not be an issue. What features is modern Fortran missing that
> you need C++ for?
>
>> F2C fixes the other big problem
>> automatically, the change of initial array index from one to zero.
>
> If I remember correctly, it does so by issueing invalid C (or
> C++), by using negative offsets from pointers. Might work now,
> might not work tomorrow.
>
> But note the IIRC above.

I want to move to a monolanguage environment. 50,000 lines of my
calculation engine are C++ already. 850,000 lines to go.

Here is a portion of the translated C++ code from a subroutine called
vapres.f. component_data1.triplepointtemperature is a previous fortran
common block variable, it is now a static. The index before was [k],
now it is [k - 1]. t and star are an argument variables.

int vapres (integer k, doublereal t, doublereal *ps, char *star,
doublereal *apc,
doublereal *atb, doublereal *atc, longint *idcomp, doublereal *zcd)
{

if (t <= component_data1.triplepointtemperature[k - 1]) {
solid_vapor_pressure (k, t, ps);
*star = ' ';
goto L99999;
}

L99999:
if (*ps < 1e-20) {
*ps = 1e-20;
}
if (*ps > 1e6) {
*ps = 1e6;
}
return 0;

} /* vapres */


Lynn

[Lawrence D'Oliveiro]

On Fri, 25 Oct 2024 20:26:37 -0500, Lynn McGuire wrote:

> {
>
> if (t <= component_data1.triplepointtemperature[k - 1]) {
> solid_vapor_pressure (k, t, ps);
> *star = ' ';
> goto L99999;
> }
>
> L99999:
> if (*ps < 1e-20) {
> *ps = 1e-20;
> }
> if (*ps > 1e6) {
> *ps = 1e6;
> }
> return 0;
>
> } /* vapres */

{
if (t <= component_data1.triplepointtemperature[k - 1])
{
solid_vapor_pressure(k, t, ps);
*star = ' ';
} /*if*/
*ps = fmin(fmax(*ps, 1e-20), 1e6);
return 0;
} /* vapres */

[Lynn McGuire]

On 10/25/2024 9:49 PM, Lawrence D'Oliveiro wrote:
> On Fri, 25 Oct 2024 20:26:37 -0500, Lynn McGuire wrote:
>
>> {
>>
>> if (t <= component_data1.triplepointtemperature[k - 1]) {
>> solid_vapor_pressure (k, t, ps);
>> *star = ' ';
>> goto L99999;
>> }
>>
>> L99999:
>> if (*ps < 1e-20) {
>> *ps = 1e-20;
>> }
>> if (*ps > 1e6) {
>> *ps = 1e6;
>> }
>> return 0;
>>
>> } /* vapres */
>
> {
> if (t <= component_data1.triplepointtemperature[k - 1])
> {
> solid_vapor_pressure(k, t, ps);
> *star = ' ';
> } /*if*/
> *ps = fmin(fmax(*ps, 1e-20), 1e6);
> return 0;
> } /* vapres */

BTW, I reduced this function from 250 lines of C++ to what you saw here
to reduce the complexity of the posting. There are several jumps to L99999.

Lynn

[Thomas Koenig]

Lynn McGuire <***@gmail.com> schrieb:
> On 10/24/2024 1:28 AM, Thomas Koenig wrote:
>> Lynn McGuire <***@gmail.com> schrieb:

>>> F2C fixes the other big problem
>>> automatically, the change of initial array index from one to zero.
>>
>> If I remember correctly, it does so by issueing invalid C (or
>> C++), by using negative offsets from pointers. Might work now,
>> might not work tomorrow.
>>
>> But note the IIRC above.
>
> I want to move to a monolanguage environment. 50,000 lines of my
> calculation engine are C++ already. 850,000 lines to go.

That motivation, I understand, especially if the GUI code is in C++,
but there is a caveat. Consider

subroutine foo(i,n)
integer array(10)
common array
integer n
integer i(n)
integer k
do k=1,n
i(k) = k + array(k)
end do
end

which gets translated by stock f2c (to which you may have made
adjustments) into

#include "f2c.h"

/* Common Block Declarations */

struct {
integer array[10];
} _BLNK__;

#define _BLNK__1 _BLNK__

/* Subroutine */ int foo_(integer *i__, integer *n)
{
/* System generated locals */
integer i__1;

/* Local variables */
static integer k;

/* Parameter adjustments */
--i__;

/* Function Body */
i__1 = *n;
for (k = 1; k <= i__1; ++k) {
i__[k] = k + _BLNK__1.array[k - 1];
}
return 0;
} /* foo_ */

The common block handling looks OK, but the dummy argument
(aka parameters, in C parlance) handling is very probably not.

The "parameter adjustment" above is explicitly listed as undefined
behavior, in annex J2 of n2596.pdf (for example):

"Addition or subtraction of a pointer into, or just beyond, an
array object and an integer type produces a result that does not
point into, or just beyond, the same array object (6.5.6)."

Undefined behavior is the worst kind of error in your program
that you can have in C, it is not required to be diagnosed, and
compilers can, and do, make optimizations based on the assumption
that it does not happen, so this is liable to break in unforseen
circumstances.

So if your version of f2c does the same, I would check the C++
standard if if has a similar provision (I strongly suspect so,
but I don't know), and, if that is the case, modify your version
of f2c to generate conforming code for array dummy arguments.
Otherwise, you are betting your company.

[Lawrence D'Oliveiro]

On Sat, 26 Oct 2024 11:51:42 -0000 (UTC), Thomas Koenig wrote:

> The "parameter adjustment" above is explicitly listed as undefined
> behavior, in annex J2 of n2596.pdf (for example):
>
> "Addition or subtraction of a pointer into, or just beyond, an array
> object and an integer type produces a result that does not point into,
> or just beyond, the same array object (6.5.6)."

Read it again: note the qualification “that does not point into, or just
beyond, the same array object”. So long as it *does* point “into, or just
beyond, the same array object”, it is fine.

[Thomas Koenig]

Lawrence D'Oliveiro <***@nz.invalid> schrieb:
> On Sat, 26 Oct 2024 11:51:42 -0000 (UTC), Thomas Koenig wrote:
>
>> The "parameter adjustment" above is explicitly listed as undefined
>> behavior, in annex J2 of n2596.pdf (for example):
>>
>> "Addition or subtraction of a pointer into, or just beyond, an array
>> object and an integer type produces a result that does not point into,
>> or just beyond, the same array object (6.5.6)."
>
> Read it again: note the qualification “that does not point into, or just
> beyond, the same array object”. So long as it *does* point “into, or just
> beyond, the same array object”, it is fine.

What you are writing is equivalent to

if (.false.) then

[Lawrence D'Oliveiro]

On Sat, 26 Oct 2024 21:38:38 -0000 (UTC), Thomas Koenig wrote:

> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>
>> On Sat, 26 Oct 2024 11:51:42 -0000 (UTC), Thomas Koenig wrote:
>>
>>> The "parameter adjustment" above is explicitly listed as undefined
>>> behavior, in annex J2 of n2596.pdf (for example):
>>>
>>> "Addition or subtraction of a pointer into, or just beyond, an array
>>> object and an integer type produces a result that does not point into,
>>> or just beyond, the same array object (6.5.6)."
>>
>> Read it again: note the qualification “that does not point into, or
>> just beyond, the same array object”. So long as it *does* point “into,
>> or just beyond, the same array object”, it is fine.
>
> What you are writing is equivalent to

You don’t understand what pointer arithmetic means, do you?

[Thomas Koenig]

Lawrence D'Oliveiro <***@nz.invalid> schrieb:
> On Sat, 26 Oct 2024 21:38:38 -0000 (UTC), Thomas Koenig wrote:
>
>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>
>>> On Sat, 26 Oct 2024 11:51:42 -0000 (UTC), Thomas Koenig wrote:
>>>
>>>> The "parameter adjustment" above is explicitly listed as undefined
>>>> behavior, in annex J2 of n2596.pdf (for example):
>>>>
>>>> "Addition or subtraction of a pointer into, or just beyond, an array
>>>> object and an integer type produces a result that does not point into,
>>>> or just beyond, the same array object (6.5.6)."
>>>
>>> Read it again: note the qualification “that does not point into, or
>>> just beyond, the same array object”. So long as it *does* point “into,
>>> or just beyond, the same array object”, it is fine.
>>
>> What you are writing is equivalent to
>
> You don’t understand what pointer arithmetic means, do you?

I've killfiled you in comp.arch, and I think it is a good time now
for comp.lang.fortran.

[Harold Stevens]

In <vfks8r$6vrt$***@dont-email.me> Thomas Koenig:

> I've killfiled you in comp.arch, and I think it is a good time now
> for comp.lang.fortran.

+1

Usenet quality of service improvement (signal to noise ratio).

--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at att, dotted with net. * DO NOT SPAM IT. *
I toss GoogleGroup (http://twovoyagers.com/improve-usenet.org/).

[Lawrence D'Oliveiro]

On Sun, 27 Oct 2024 08:05:47 -0000 (UTC), Thomas Koenig wrote:

> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>
>> On Sat, 26 Oct 2024 21:38:38 -0000 (UTC), Thomas Koenig wrote:
>>
>>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>>
>>>> On Sat, 26 Oct 2024 11:51:42 -0000 (UTC), Thomas Koenig wrote:
>>>>
>>>>> The "parameter adjustment" above is explicitly listed as undefined
>>>>> behavior, in annex J2 of n2596.pdf (for example):
>>>>>
>>>>> "Addition or subtraction of a pointer into, or just beyond, an array
>>>>> object and an integer type produces a result that does not point
>>>>> into, or just beyond, the same array object (6.5.6)."
>>>>
>>>> Read it again: note the qualification “that does not point into, or
>>>> just beyond, the same array object”. So long as it *does* point
>>>> “into, or just beyond, the same array object”, it is fine.
>>>
>>> What you are writing is equivalent to
>>
>> You don’t understand what pointer arithmetic means, do you?

Hey, look! Somebody who doesn’t understand how pointer arithmetic works!

[Lynn McGuire]

On 10/27/2024 4:01 PM, Lawrence D'Oliveiro wrote:
> On Sun, 27 Oct 2024 08:05:47 -0000 (UTC), Thomas Koenig wrote:
>
>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>>
>>> On Sat, 26 Oct 2024 21:38:38 -0000 (UTC), Thomas Koenig wrote:
>>>
>>>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>>>
>>>>> On Sat, 26 Oct 2024 11:51:42 -0000 (UTC), Thomas Koenig wrote:
>>>>>
>>>>>> The "parameter adjustment" above is explicitly listed as undefined
>>>>>> behavior, in annex J2 of n2596.pdf (for example):
>>>>>>
>>>>>> "Addition or subtraction of a pointer into, or just beyond, an array
>>>>>> object and an integer type produces a result that does not point
>>>>>> into, or just beyond, the same array object (6.5.6)."
>>>>>
>>>>> Read it again: note the qualification “that does not point into, or
>>>>> just beyond, the same array object”. So long as it *does* point
>>>>> “into, or just beyond, the same array object”, it is fine.
>>>>
>>>> What you are writing is equivalent to
>>>
>>> You don’t understand what pointer arithmetic means, do you?
>
> Hey, look! Somebody who doesn’t understand how pointer arithmetic works!

Are you 12 years old ?

Lynn

[James Kuyper]

On 10/27/24 17:01, Lawrence D'Oliveiro wrote:
> On Sun, 27 Oct 2024 08:05:47 -0000 (UTC), Thomas Koenig wrote:
>
>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>>
>>> On Sat, 26 Oct 2024 21:38:38 -0000 (UTC), Thomas Koenig wrote:
>>>
>>>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>>>
>>>>> On Sat, 26 Oct 2024 11:51:42 -0000 (UTC), Thomas Koenig wrote:

Lawrence snipped the following extremely relevant text from his
response, which made it very unclear what the controversy was about.

>>>>>> #include "f2c.h"
>>>>>>
>>>>>> /* Common Block Declarations */
>>>>>>
>>>>>> struct {
>>>>>> integer array[10];
>>>>>> } _BLNK__;
>>>>>>
>>>>>> #define _BLNK__1 _BLNK__
>>>>>>
>>>>>> /* Subroutine */ int foo_(integer *i__, integer *n)
>>>>>> {
>>>>>> /* System generated locals */
>>>>>> integer i__1;
>>>>>>
>>>>>> /* Local variables */
>>>>>> static integer k;
>>>>>>
>>>>>> /* Parameter adjustments */
>>>>>> --i__;
>>>>>>
>>>>>> /* Function Body */
>>>>>> i__1 = *n;
>>>>>> for (k = 1; k <= i__1; ++k) {
>>>>>> i__[k] = k + _BLNK__1.array[k - 1];
>>>>>> }
>>>>>> return 0;
>>>>>> } /* foo_ */
>>>>>>
>>>>>> The common block handling looks OK, but the dummy argument
>>>>>> (aka parameters, in C parlance) handling is very probably not.


>>>>>> The "parameter adjustment" above is explicitly listed as undefined
>>>>>> behavior, in annex J2 of n2596.pdf (for example):
>>>>>>
>>>>>> "Addition or subtraction of a pointer into, or just beyond, an array
>>>>>> object and an integer type produces a result that does not point
>>>>>> into, or just beyond, the same array object (6.5.6)."
[snipped ensuing conversation, which contained nothing of value.]

It would be more appropriate to cite 6.5.6 itself, rather than Annex J2,
which is just a summary. The summary often doesn't go into as much
detail as the clause being summarized, and the details that are left out
of the summary are occasionally relevant.
It would also be better to cite a newer version of the standard. The
latest I have is n3096, dated 2023-04-01 (but it's not an April Fool's
joke), and in that version 6.5.6p10 says:

"If the pointer operand and the result do not point to elements of the
same array object or one past the last element of the array object, the
behavior is undefined."

However, there was equivalent wording in all previous versions of the C
standard, so it doesn't really matter which version you look at.

As far as C is concerned, whether or not the adjustment had undefined
behavior depends entirely upon where i__ points when foo_() is called.
If it points at any location in an array other than the first element of
the array (including one past the end of the array), then --i__ is
perfectly legal, because the result will point at an earlier element of
the same array. For instance, this would be perfectly legal:

integer array[11]={0};
int ret = foo_(array + 1, 10);

I've seen code like this used to make C code look more like the Fortran
it was translated from, and in that context a function like this would
be called with a pointer to the first element of an array, in which case
the behavior is indeed undefined, which is why that's a bad way to
handle the translation. But it's the combination of foo_()'s definition,
and how it is called, that make the behavior undefined, not just the
code of foo_() itself.

[Waldek Hebisch]

In comp.lang.c James Kuyper <***@alumni.caltech.edu> wrote:
> On 10/27/24 17:01, Lawrence D'Oliveiro wrote:
>> On Sun, 27 Oct 2024 08:05:47 -0000 (UTC), Thomas Koenig wrote:
>>
>>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>>>
>>>> On Sat, 26 Oct 2024 21:38:38 -0000 (UTC), Thomas Koenig wrote:
>>>>
>>>>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>>>>
>>>>>> On Sat, 26 Oct 2024 11:51:42 -0000 (UTC), Thomas Koenig wrote:
>
> Lawrence snipped the following extremely relevant text from his
> response, which made it very unclear what the controversy was about.
>
>>>>>>> #include "f2c.h"
>>>>>>>
>>>>>>> /* Common Block Declarations */
>>>>>>>
>>>>>>> struct {
>>>>>>> integer array[10];
>>>>>>> } _BLNK__;
>>>>>>>
>>>>>>> #define _BLNK__1 _BLNK__
>>>>>>>
>>>>>>> /* Subroutine */ int foo_(integer *i__, integer *n)
>>>>>>> {
>>>>>>> /* System generated locals */
>>>>>>> integer i__1;
>>>>>>>
>>>>>>> /* Local variables */
>>>>>>> static integer k;
>>>>>>>
>>>>>>> /* Parameter adjustments */
>>>>>>> --i__;
>>>>>>>
>>>>>>> /* Function Body */
>>>>>>> i__1 = *n;
>>>>>>> for (k = 1; k <= i__1; ++k) {
>>>>>>> i__[k] = k + _BLNK__1.array[k - 1];
>>>>>>> }
>>>>>>> return 0;
>>>>>>> } /* foo_ */
>>>>>>>
>>>>>>> The common block handling looks OK, but the dummy argument
>>>>>>> (aka parameters, in C parlance) handling is very probably not.
>
>
>>>>>>> The "parameter adjustment" above is explicitly listed as undefined
>>>>>>> behavior, in annex J2 of n2596.pdf (for example):
>>>>>>>
>>>>>>> "Addition or subtraction of a pointer into, or just beyond, an array
>>>>>>> object and an integer type produces a result that does not point
>>>>>>> into, or just beyond, the same array object (6.5.6)."
> [snipped ensuing conversation, which contained nothing of value.]
>
> It would be more appropriate to cite 6.5.6 itself, rather than Annex J2,
> which is just a summary. The summary often doesn't go into as much
> detail as the clause being summarized, and the details that are left out
> of the summary are occasionally relevant.
> It would also be better to cite a newer version of the standard. The
> latest I have is n3096, dated 2023-04-01 (but it's not an April Fool's
> joke), and in that version 6.5.6p10 says:
>
> "If the pointer operand and the result do not point to elements of the
> same array object or one past the last element of the array object, the
> behavior is undefined."
>
> However, there was equivalent wording in all previous versions of the C
> standard, so it doesn't really matter which version you look at.
>
> As far as C is concerned, whether or not the adjustment had undefined
> behavior depends entirely upon where i__ points when foo_() is called.
> If it points at any location in an array other than the first element of
> the array (including one past the end of the array), then --i__ is
> perfectly legal, because the result will point at an earlier element of
> the same array. For instance, this would be perfectly legal:
>
> integer array[11]={0};
> int ret = foo_(array + 1, 10);
>
> I've seen code like this used to make C code look more like the Fortran
> it was translated from, and in that context a function like this would
> be called with a pointer to the first element of an array, in which case
> the behavior is indeed undefined, which is why that's a bad way to
> handle the translation. But it's the combination of foo_()'s definition,
> and how it is called, that make the behavior undefined, not just the
> code of foo_() itself.

There is more context to this: AFAICS the relevant use case is
handling Fortran/f2c calling convention where on entry to the function
the pointer points to first element of Fortran array. This element
has index 1 in Fortran but would have index 0 in generated C code.
f2c wanted to use the same indices as in Fortran, so is doing "adjustment".
But the resulting base pointer points one element before array,
so in normal use 6.5.6 applies.

In effect, in this case Lawrence is making noise but the other
folks are correct.

--
Waldek Hebisch

[Lynn McGuire]

On 10/27/2024 3:05 AM, Thomas Koenig wrote:
> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>> On Sat, 26 Oct 2024 21:38:38 -0000 (UTC), Thomas Koenig wrote:
>>
>>> Lawrence D'Oliveiro <***@nz.invalid> schrieb:
>>>
>>>> On Sat, 26 Oct 2024 11:51:42 -0000 (UTC), Thomas Koenig wrote:
>>>>
>>>>> The "parameter adjustment" above is explicitly listed as undefined
>>>>> behavior, in annex J2 of n2596.pdf (for example):
>>>>>
>>>>> "Addition or subtraction of a pointer into, or just beyond, an array
>>>>> object and an integer type produces a result that does not point into,
>>>>> or just beyond, the same array object (6.5.6)."
>>>>
>>>> Read it again: note the qualification “that does not point into, or
>>>> just beyond, the same array object”. So long as it *does* point “into,
>>>> or just beyond, the same array object”, it is fine.
>>>
>>> What you are writing is equivalent to
>>
>> You don’t understand what pointer arithmetic means, do you?
>
> I've killfiled you in comp.arch, and I think it is a good time now
> for comp.lang.fortran.

Hi Thomas, I am sorry to cause you trouble. The unofficial language
lawyers are amazing in going beyond the scope of the initial question.

Sincerely,
Lynn

[Lynn McGuire]

On 10/26/2024 6:51 AM, Thomas Koenig wrote:
> Lynn McGuire <***@gmail.com> schrieb:
>> On 10/24/2024 1:28 AM, Thomas Koenig wrote:
>>> Lynn McGuire <***@gmail.com> schrieb:
>
>>>> F2C fixes the other big problem
>>>> automatically, the change of initial array index from one to zero.
>>>
>>> If I remember correctly, it does so by issueing invalid C (or
>>> C++), by using negative offsets from pointers. Might work now,
>>> might not work tomorrow.
>>>
>>> But note the IIRC above.
>>
>> I want to move to a monolanguage environment. 50,000 lines of my
>> calculation engine are C++ already. 850,000 lines to go.
>
> That motivation, I understand, especially if the GUI code is in C++,
> but there is a caveat. Consider
>
> subroutine foo(i,n)
> integer array(10)
> common array
> integer n
> integer i(n)
> integer k
> do k=1,n
> i(k) = k + array(k)
> end do
> end
>
> which gets translated by stock f2c (to which you may have made
> adjustments) into
>
> #include "f2c.h"
>
> /* Common Block Declarations */
>
> struct {
> integer array[10];
> } _BLNK__;
>
> #define _BLNK__1 _BLNK__
>
> /* Subroutine */ int foo_(integer *i__, integer *n)
> {
> /* System generated locals */
> integer i__1;
>
> /* Local variables */
> static integer k;
>
> /* Parameter adjustments */
> --i__;
>
> /* Function Body */
> i__1 = *n;
> for (k = 1; k <= i__1; ++k) {
> i__[k] = k + _BLNK__1.array[k - 1];
> }
> return 0;
> } /* foo_ */
>
> The common block handling looks OK, but the dummy argument
> (aka parameters, in C parlance) handling is very probably not.
>
> The "parameter adjustment" above is explicitly listed as undefined
> behavior, in annex J2 of n2596.pdf (for example):
>
> "Addition or subtraction of a pointer into, or just beyond, an
> array object and an integer type produces a result that does not
> point into, or just beyond, the same array object (6.5.6)."
>
> Undefined behavior is the worst kind of error in your program
> that you can have in C, it is not required to be diagnosed, and
> compilers can, and do, make optimizations based on the assumption
> that it does not happen, so this is liable to break in unforseen
> circumstances.
>
> So if your version of f2c does the same, I would check the C++
> standard if if has a similar provision (I strongly suspect so,
> but I don't know), and, if that is the case, modify your version
> of f2c to generate conforming code for array dummy arguments.
> Otherwise, you are betting your company.

First, I include all of my 300+ common blocks as 200 files. I converted
those separately and cleaned them up so that the static variables and
defines are easy to peruse and understand. I delete all of the local
common block conversions by f2c in the subroutines and change them back
to include files. An easy cleanup that I have to do 5,000 times (4,000
to go now plus the 100+ subroutines that we have modified for customers
since I started the conversion project two years ago).

I also removed the parameter adjustments from my copy of f2c. It is a
little tricky but as you say, they are not legal code in C++.

I have extensively modified my copy of f2c so that it generates better
legal C++ code and many other improvements. But my changes are subject
to the old 80 / 20 rule. I have 80% automated conversions and 20% hand
conversions. I do have a little experience here: Fortran since 1975, C
since 1987, and C++ since 2000.

Thanks for the warnings,
Lynn

[Thomas Koenig]

Lynn McGuire <***@gmail.com> schrieb:

> First, I include all of my 300+ common blocks as 200 files. I converted
> those separately and cleaned them up so that the static variables and
> defines are easy to peruse and understand. I delete all of the local
> common block conversions by f2c in the subroutines and change them back
> to include files. An easy cleanup that I have to do 5,000 times (4,000
> to go now plus the 100+ subroutines that we have modified for customers
> since I started the conversion project two years ago).

Sounds like a lot of work...

>
> I also removed the parameter adjustments from my copy of f2c. It is a
> little tricky but as you say, they are not legal code in C++.

Very good, I think you're set then.

[Lynn McGuire]

On 10/26/2024 4:30 PM, Thomas Koenig wrote:
> Lynn McGuire <***@gmail.com> schrieb:
>
>> First, I include all of my 300+ common blocks as 200 files. I converted
>> those separately and cleaned them up so that the static variables and
>> defines are easy to peruse and understand. I delete all of the local
>> common block conversions by f2c in the subroutines and change them back
>> to include files. An easy cleanup that I have to do 5,000 times (4,000
>> to go now plus the 100+ subroutines that we have modified for customers
>> since I started the conversion project two years ago).
>
> Sounds like a lot of work...
>
>>
>> I also removed the parameter adjustments from my copy of f2c. It is a
>> little tricky but as you say, they are not legal code in C++.
>
> Very good, I think you're set then.

It is an incredible amount of work. That and the conversion of the rest
of the programs and DLLs for our app will probably be my last major
project in my career. But once done, it will allow our app to move
forward into the 64 bit world in a somewhat organized manner. I
actually have users running out of memory as a Win32 program now.

I was totally impressed by the work and scope of F2C. It is my
understanding that it is the front end for the old F77 compiler. Making
my changes to generate better code for the conversion of our F77 code to
C++ code was not hard, just tedious to figure out the multiple passes
and interpass data storage.

Thanks,
Lynn

[Lynn McGuire]

On 10/3/2024 5:34 PM, Lawrence D'Oliveiro wrote:
> On Thu, 3 Oct 2024 17:13:40 -0500, Lynn McGuire wrote:
>
>> On 10/3/2024 5:08 PM, Lawrence D'Oliveiro wrote:
>>>
>>> On Thu, 3 Oct 2024 14:32:28 -0500, Lynn McGuire wrote:
>>>
>>>> I have 197 common blocks included from dedicated files and a massive
>>>> number of equivalences all over the place.
>>>
>>> Try getting rid of at least some of them, by using “contains”.
>>
>> What does "contains" do ? My knowledge of Fortran stopped at F77+.
>
> Pick up a Fortran-90-or-later spec. This is not your father’s Fortran any
> more. “contains” lets you put subroutines and functions directly in the
> main program, so they can refer directly to program globals instead of
> having to go through “common” blocks.
>
> I posted an example of modernized Fortran code right here a few months
> ago, and I see there’s a comment from you on it, so you must have seen it.

Ah yes, the Lunar Lander game.

I played that game back in 1971 on the operator console teletype for a
Univac 1108. Was a blast. Ran through an entire roll of paper that
night while my Dad was chasing a bug in the software that I have been
working on since 1975.

Here is something about the Fortran Contains:
https://stackoverflow.com/questions/35808053/contains-statement

Lynn

[Thomas Koenig]

Lynn McGuire <***@gmail.com> schrieb:

> I have 197 common blocks included from dedicated files and a massive
> number of equivalences all over the place. Several of the equivalences
> are actually in the common block files. The equivalences have made the
> eventual C++ conversion of the Fortran code tricky.

What do you use the equivalences for? Saving memory? Then this
should not be a large issue on modern machines.

If you are using them for tricks with type conversion, then you
are on thin ice already, and have been since Fortran 66.

And if you have a few big arrays, then changing those to ALLOCATABLE
and allocating them at runtime might well be straightforward.

[R Daneel Olivaw]

Thomas Koenig wrote:
> Lynn McGuire <***@gmail.com> schrieb:
>
>> I have 197 common blocks included from dedicated files and a massive
>> number of equivalences all over the place. Several of the equivalences
>> are actually in the common block files. The equivalences have made the
>> eventual C++ conversion of the Fortran code tricky.
>
> What do you use the equivalences for? Saving memory? Then this
> should not be a large issue on modern machines.
>
> If you are using them for tricks with type conversion, then you
> are on thin ice already, and have been since Fortran 66.
>
> And if you have a few big arrays, then changing those to ALLOCATABLE
> and allocating them at runtime might well be straightforward.
>

Equivalences are an effective way of building data structures, you can
do that with Common as well but sometimes equivalence is more suitable.

[Thomas Koenig]

R Daneel Olivaw <***@hyperspace.vogon.gov> schrieb:

> Equivalences are an effective way of building data structures, you can
> do that with Common as well but sometimes equivalence is more suitable.

Can you give an example? I have a hard time imagining what it would
be useful for.

[R Daneel Olivaw]

Thomas Koenig wrote:
> R Daneel Olivaw <***@hyperspace.vogon.gov> schrieb:
>
>> Equivalences are an effective way of building data structures, you can
>> do that with Common as well but sometimes equivalence is more suitable.
>
> Can you give an example? I have a hard time imagining what it would
> be useful for.
>

integer record (100), reckey, reccod
c or integer*4
character*40 recnam, recstr, rectwn
c
equivalence (record, reckey), (record (2), recnam)
equivalence (record (12), recstr), (record (22), rectwn)
equivalence (record (32), reccod)
c and so on

I have used constructs like that to handle database structures, although
obviously we were restricted to whole-word fields and multiple-word
fields - with everything being on word boundaries.
One Fortran implementation I used for years allowed us to use statement
functions to implement partial-word fields, these functions could be
used on the left or the right sides of an assignment.
That permitted far more fine tuning.

[Lawrence D'Oliveiro]

On Sun, 13 Oct 2024 17:21:38 +0200, R Daneel Olivaw wrote:

> integer record (100), reckey, reccod
> c or integer*4
> character*40 recnam, recstr, rectwn
> c
> equivalence (record, reckey), (record (2), recnam)
> equivalence (record (12), recstr), (record (22), rectwn)
> equivalence (record (32), reccod)
> c and so on

So much simpler nowadays:

integer, parameter :: intsize = kind(0) ! or 4 for integer*4
integer, parameter :: strmax = 40

type :: record_type
integer(kind = intsize) reckey
character(len = strmax) :: recnam, recstr, recwn
integer(kind = intsize) reccod
! and so on
end type record_type

! declare a variable of the type:
type(record_type) :: a_record
! fields accessible as “a_record % reckey”, “a_record % recname” etc

(Not actually tested, but you get the idea.)

[Lawrence D'Oliveiro]

On Sun, 13 Oct 2024 21:03:25 -0000 (UTC), I wrote:

> type :: record_type
> integer(kind = intsize) reckey
> character(len = strmax) :: recnam, recstr, recwn
> integer(kind = intsize) reccod
> ! and so on
> end type record_type

Hmm, need to put a “sequence” line in there as well.

[Gary Scott]

On 10/13/2024 7:18 AM, Thomas Koenig wrote:
> Lynn McGuire <***@gmail.com> schrieb:
>
>> I have 197 common blocks included from dedicated files and a massive
>> number of equivalences all over the place. Several of the equivalences
>> are actually in the common block files. The equivalences have made the
>> eventual C++ conversion of the Fortran code tricky.
>
> What do you use the equivalences for? Saving memory? Then this
> should not be a large issue on modern machines.

About the only thing I've used it for is for performing mathematical
operations on things like characters for encryption or compression
algorithms. Using a function for that doesn't appeal to me.

>
> If you are using them for tricks with type conversion, then you
> are on thin ice already, and have been since Fortran 66.
>
> And if you have a few big arrays, then changing those to ALLOCATABLE
> and allocating them at runtime might well be straightforward.

[Lawrence D'Oliveiro]

On Sun, 13 Oct 2024 09:12:15 -0500, Gary Scott wrote:

> On 10/13/2024 7:18 AM, Thomas Koenig wrote:
>>
>> What do you use the equivalences for?
>
> About the only thing I've used it for is for performing mathematical
> operations on things like characters for encryption or compression
> algorithms. Using a function for that doesn't appeal to me.

Builtin functions/methods are the way that sort of thing is done in all
the proper high-level languages. If you are afraid of code efficiency,
don’t be; the compiler knows how to generate good code for its own
intrinsics.

[Lynn McGuire]

On 10/13/2024 7:18 AM, Thomas Koenig wrote:
> Lynn McGuire <***@gmail.com> schrieb:
>
>> I have 197 common blocks included from dedicated files and a massive
>> number of equivalences all over the place. Several of the equivalences
>> are actually in the common block files. The equivalences have made the
>> eventual C++ conversion of the Fortran code tricky.
>
> What do you use the equivalences for? Saving memory? Then this
> should not be a large issue on modern machines.
>
> If you are using them for tricks with type conversion, then you
> are on thin ice already, and have been since Fortran 66.
>
> And if you have a few big arrays, then changing those to ALLOCATABLE
> and allocating them at runtime might well be straightforward.

Ripping this out of my F77 code would be a monumentous project. Over
100,000 lines of code reference the memory allocation scheme that we
have used in Fortran since 1977. We name the thousands of memory blocks
for multiple references and put overwrite detection in them. No thanks.

Lynn

[Lynn McGuire]

On 10/13/2024 7:18 AM, Thomas Koenig wrote:
> Lynn McGuire <***@gmail.com> schrieb:
>
>> I have 197 common blocks included from dedicated files and a massive
>> number of equivalences all over the place. Several of the equivalences
>> are actually in the common block files. The equivalences have made the
>> eventual C++ conversion of the Fortran code tricky.
>
> What do you use the equivalences for? Saving memory? Then this
> should not be a large issue on modern machines.
>
> If you are using them for tricks with type conversion, then you
> are on thin ice already, and have been since Fortran 66.
>
> And if you have a few big arrays, then changing those to ALLOCATABLE
> and allocating them at runtime might well be straightforward.

"DYNOSOR: a set of subroutines for dynamic memory organization in
Fortran programs"
https://dl.acm.org/doi/10.1145/954654.954661

One of our guys went to an ACM conference in 1977 and came back with
this paper. It was the answer to our memory problems on the Univac
1108, the CDC 7600, and later the IBM 370.

I converted the memory allocation scheme from a common block in 1992 ???
to using the C malloc, realloc, and free library functions. Worked like
a champ on Unix, Vax VMS, IBM mainframes, and PC DOS using various F77
compilers.

Before that I was having to ship special special versions to certain
customers that were extensively using our builtin Fortran interpreter
for custom calculations to design highly specialized chemical reactors.

Lynn

[Thomas Koenig]

Lynn McGuire <***@gmail.com> schrieb:

> "DYNOSOR: a set of subroutines for dynamic memory organization in
> Fortran programs"
> https://dl.acm.org/doi/10.1145/954654.954661
>
> One of our guys went to an ACM conference in 1977 and came back with
> this paper. It was the answer to our memory problems on the Univac
> 1108, the CDC 7600, and later the IBM 370.

Only the first page is readable, the rest is behind paywall,
unfortunately.

>
> I converted the memory allocation scheme from a common block in 1992 ???
> to using the C malloc, realloc, and free library functions. Worked like
> a champ on Unix, Vax VMS, IBM mainframes, and PC DOS using various F77
> compilers.

If you're already using dynamic allocation, then you can of course
keep on doing what you are doing. It will not be officially
supported, but the likelyhood of this continuing to work is high
(no guarantees, though).

[R Daneel Olivaw]

Thomas Koenig wrote:
> Lynn McGuire <***@gmail.com> schrieb:
>
>> "DYNOSOR: a set of subroutines for dynamic memory organization in
>> Fortran programs"
>> https://dl.acm.org/doi/10.1145/954654.954661
>>
>> One of our guys went to an ACM conference in 1977 and came back with
>> this paper. It was the answer to our memory problems on the Univac
>> 1108, the CDC 7600, and later the IBM 370.
>
> Only the first page is readable, the rest is behind paywall,
> unfortunately.
>
>>
>> I converted the memory allocation scheme from a common block in 1992 ???
>> to using the C malloc, realloc, and free library functions. Worked like
>> a champ on Unix, Vax VMS, IBM mainframes, and PC DOS using various F77
>> compilers.
>
> If you're already using dynamic allocation, then you can of course
> keep on doing what you are doing. It will not be officially
> supported, but the likelyhood of this continuing to work is high
> (no guarantees, though).
>

If it ain't broke, don't fix it.
(unless there are really good reasons)

[Louis Krupp]

On 10/15/2024 12:28 AM, Thomas Koenig wrote:
> Lynn McGuire<***@gmail.com> schrieb:
>
>> "DYNOSOR: a set of subroutines for dynamic memory organization in
>> Fortran programs"
>> https://dl.acm.org/doi/10.1145/954654.954661
>>
>> One of our guys went to an ACM conference in 1977 and came back with
>> this paper. It was the answer to our memory problems on the Univac
>> 1108, the CDC 7600, and later the IBM 370.
> Only the first page is readable, the rest is behind paywall,
> unfortunately.
>
<snip>

I went to that page, clicked on a red button that said "PDF," and got
what looks like the whole article -- all without having to log into an
ACM account (I'm pretty sure I don't have one).

I remember reading a few years ago that ACM made everything published
earlier than a certain date freely accessible, and I'm guessing that
April of 1977 is old enough.

(In April of 1977, I was 25 years old and working for Burroughs Federal
Systems. I knew enough FORTRAN to help users at a civilian agency get
their programs working, but that was about it. As far as I was
concerned, Burroughs Extended ALGOL was where it was at. I never would
have guessed that 47 years later, FORTRAN would be Fortran and ALGOL
would be mostly forgotten.)

Louis

[Lawrence D'Oliveiro]

On Tue, 15 Oct 2024 02:43:47 -0600, Louis Krupp wrote:

> I never would
> have guessed that 47 years later, FORTRAN would be Fortran and ALGOL
> would be mostly forgotten.)

What irks me most is the prevalence of “=” over “:=” for assignment.

But, looking at language specs for Fortran-90 and later, would you still
say “FORTRAN is Fortran”?

[Louis Krupp]

On 10/15/2024 4:32 PM, Lawrence D'Oliveiro wrote:
> On Tue, 15 Oct 2024 02:43:47 -0600, Louis Krupp wrote:
>
>> I never would
>> have guessed that 47 years later, FORTRAN would be Fortran and ALGOL
>> would be mostly forgotten.)
> What irks me most is the prevalence of “=” over “:=” for assignment.
>
> But, looking at language specs for Fortran-90 and later, would you still
> say “FORTRAN is Fortran”?

"... FORTRAN would have become Fortran" would have been more accurate,
but since one could make the case that FORTRAN exists today only as an
often read but rarely written subset of Fortran, and since I wrote that
post at a quarter to three in the morning, I'll ask everyone to bear
with me.

FORTRAN was my first (computer) language. I was taking a class called
Computer Math in high school and we ran, or tried to run, programs on an
IBM 1440. Nothing I did worked because I'd punched "FORTRAN LOAD" or
"FORTRAN RUN" in column 6 instead of column 7 or something and nobody
spotted it. When we went on to writing ALGOL programs for a Burroughs
B5500, the columns didn't matter as much, and I got stuff to run. The
assignment operator was a left arrow, which had a six-bit code in BCL
(Burroughs Common Language), and a punch code, and that made sense. When
the B5500 was replaced by a B6700, which used EBCDIC, ALGOL used ":="
instead of the arrow, which I missed.

Louis

[Lawrence D'Oliveiro]

On Tue, 15 Oct 2024 17:54:51 -0600, Louis Krupp wrote:

> FORTRAN was my first (computer) language.

Mine, too. Though I picked up “Programming In POP-2” soon after, and had
my mind suitably blown.

I think that gave me a sense of perspective about BASIC when I first
encountered that.

> the B5500 was replaced by a B6700, which used EBCDIC, ALGOL used ":="
> instead of the arrow, which I missed.

Nowadays, with Unicode, you can have “←” as well as “:=”. There is even
U+2254 COLON EQUALS, “≔” as one character.

[Lynn McGuire]

On 10/15/2024 1:28 AM, Thomas Koenig wrote:
> Lynn McGuire <***@gmail.com> schrieb:
>
>> "DYNOSOR: a set of subroutines for dynamic memory organization in
>> Fortran programs"
>> https://dl.acm.org/doi/10.1145/954654.954661
>>
>> One of our guys went to an ACM conference in 1977 and came back with
>> this paper. It was the answer to our memory problems on the Univac
>> 1108, the CDC 7600, and later the IBM 370.
>
> Only the first page is readable, the rest is behind paywall,
> unfortunately.
>
>>
>> I converted the memory allocation scheme from a common block in 1992 ???
>> to using the C malloc, realloc, and free library functions. Worked like
>> a champ on Unix, Vax VMS, IBM mainframes, and PC DOS using various F77
>> compilers.
>
> If you're already using dynamic allocation, then you can of course
> keep on doing what you are doing. It will not be officially
> supported, but the likelyhood of this continuing to work is high
> (no guarantees, though).

There are no guarantees for anything in life ! Hardware and software
are the worst of all for consistency.

I am thinking that 32 bit and 64 bit are here to stay for quite a while.
I am wondering what will be next, 128 bit (already in planning) or 256
bit.

Lynn

[Lawrence D'Oliveiro]

On Tue, 15 Oct 2024 17:03:01 -0500, Lynn McGuire wrote:

> I am thinking that 32 bit and 64 bit are here to stay for quite a while.

I think typical memory sizes are doubling maybe every couple of years, if
not sooner. Currently maybe 48-bit memory addresses are sufficient, but it
will be just a matter of a few decades before even 64-bit addresses won’t
be enough.

[Lynn McGuire]

On 10/15/2024 5:34 PM, Lawrence D'Oliveiro wrote:
> On Tue, 15 Oct 2024 17:03:01 -0500, Lynn McGuire wrote:
>
>> I am thinking that 32 bit and 64 bit are here to stay for quite a while.
>
> I think typical memory sizes are doubling maybe every couple of years, if
> not sooner. Currently maybe 48-bit memory addresses are sufficient, but it
> will be just a matter of a few decades before even 64-bit addresses won’t
> be enough.

I suspect a decade at most before 256 bit programming and addressing.

The guys at NIST are talking about quadruple precision as a standard.

Lynn

[Lawrence D'Oliveiro]

On Wed, 16 Oct 2024 17:44:06 -0500, Lynn McGuire wrote:

> The guys at NIST are talking about quadruple precision as a standard.

That’s long overdue, but not in itself a reason for going to 128-bit
addressing.

Decimal arithmetic is now in IEEE 754, we just have to wait for support
for it to become more widespread.

[R Daneel Olivaw]

Lynn McGuire wrote:
> I need many of my integers to be integer*8 in my port to 64 bit.  In
> C/C++ code, I can say 123456L to mean a long long value, generally 64
> bit.  Is there a corresponding way to do this in Fortran or am I stuck
> with:
>
>     call xyz (1)
>
>     subroutine xyz (ivalue)
>     integer*8 ivalue
>     ...
>     return end
>
> must be:
>
>     integer*8 ivalue
>     ...
>     ivalue = 1
>     call xyz (ivalue)
>
> Thanks,
> Lynn
>

This is not actually a Fortran issue as such, it's all about a specific
compiler (GNU Fortran).

[Steven G. Kargl]

On Thu, 03 Oct 2024 14:45:31 +0200, R Daneel Olivaw wrote:

> Lynn McGuire wrote:
>> I need many of my integers to be integer*8 in my port to 64 bit.  In
>> C/C++ code, I can say 123456L to mean a long long value, generally 64
>> bit.  Is there a corresponding way to do this in Fortran or am I stuck
>> with:
>>
>>     call xyz (1)
>>
>>     subroutine xyz (ivalue)
>>     integer*8 ivalue
>>     ...
>>     return end
>>
>> must be:
>>
>>     integer*8 ivalue
>>     ...
>>     ivalue = 1
>>     call xyz (ivalue)
>>
>
> This is not actually a Fortran issue as such, it's all about a specific
> compiler (GNU Fortran).

If we overlook the nonstandard type in the declaration, and agree
that the compiler will accept 'integer*8', then the program is
still invalid Fortran. It's technically not a Fortran issue. It
is a programmer issue.

--
steve

[R Daneel Olivaw]

Steven G. Kargl wrote:
> On Thu, 03 Oct 2024 14:45:31 +0200, R Daneel Olivaw wrote:
>
>> Lynn McGuire wrote:
>>> I need many of my integers to be integer*8 in my port to 64 bit.  In
>>> C/C++ code, I can say 123456L to mean a long long value, generally 64
>>> bit.  Is there a corresponding way to do this in Fortran or am I stuck
>>> with:
>>>
>>>     call xyz (1)
>>>
>>>     subroutine xyz (ivalue)
>>>     integer*8 ivalue
>>>     ...
>>>     return end
>>>
>>> must be:
>>>
>>>     integer*8 ivalue
>>>     ...
>>>     ivalue = 1
>>>     call xyz (ivalue)
>>>
>>
>> This is not actually a Fortran issue as such, it's all about a specific
>> compiler (GNU Fortran).
>
> If we overlook the nonstandard type in the declaration, and agree
> that the compiler will accept 'integer*8', then the program is
> still invalid Fortran. It's technically not a Fortran issue. It
> is a programmer issue.
>

Take a pragmatic approach, if that's the way the compiler wants you to
do it then do it that way.
Years ago I was converting a suite of programs from one OS/hardware
platform to another. One program had serious problems because type
"real" had insufficient precision on the new machine, that machine
offered a compile option which meant "real" automatically meant "double
precision" and - after checking for "equivalence" and common" statements
- that's the way I went. Problem solved. This was back in the days of
Fortran IV but I don't think I've ever seen anyone assigning Hollerith
values to Real numbers so that was not a problem either.

[Lynn McGuire]

On 10/3/2024 12:02 PM, R Daneel Olivaw wrote:
> Steven G. Kargl wrote:
>> On Thu, 03 Oct 2024 14:45:31 +0200, R Daneel Olivaw wrote:
>>
>>> Lynn McGuire wrote:
>>>> I need many of my integers to be integer*8 in my port to 64 bit.  In
>>>> C/C++ code, I can say 123456L to mean a long long value, generally 64
>>>> bit.  Is there a corresponding way to do this in Fortran or am I stuck
>>>> with:
>>>>
>>>>       call xyz (1)
>>>>
>>>>       subroutine xyz (ivalue)
>>>>       integer*8 ivalue
>>>>       ...
>>>>       return end
>>>>
>>>> must be:
>>>>
>>>>       integer*8 ivalue
>>>>       ...
>>>>       ivalue = 1
>>>>       call xyz (ivalue)
>>>>
>>>
>>> This is not actually a Fortran issue as such, it's all about a specific
>>> compiler (GNU Fortran).
>>
>> If we overlook the nonstandard type in the declaration, and agree
>> that the compiler will accept 'integer*8', then the program is
>> still invalid Fortran.  It's technically not a Fortran issue.  It
>> is a programmer issue.
>>
>
> Take a pragmatic approach, if that's the way the compiler wants you to
> do it then do it that way.
> Years ago I was converting a suite of programs from one OS/hardware
> platform to another.  One program had serious problems because type
> "real" had insufficient precision on the new machine, that machine
> offered a compile option which meant "real" automatically meant "double
> precision" and - after checking for "equivalence" and common" statements
> - that's the way I went.  Problem solved.  This was back in the days of
> Fortran IV but I don't think I've ever seen anyone assigning Hollerith
> values to Real numbers so that was not a problem either.

My code used to assign Hollerith to Real numbers but I ripped that out
years ago in a project to get rid of Hollerith.

Lynn

[Lawrence D'Oliveiro]

On Thu, 3 Oct 2024 14:34:01 -0500, Lynn McGuire wrote:

> My code used to assign Hollerith to Real numbers but I ripped that out
> years ago in a project to get rid of Hollerith.

Fortran was the first programming language I learned (from the Anna Burke
Harris book). The only kind of string literals I can remember in that
first learning were Hollerith literals. I liked the fact that they were
unambiguous: because length was explicit up front, you could any
characters you liked in them.

Later I discovered that “normal” people preferred explicitly-delimited
string literals.

[R Daneel Olivaw]

Lawrence D'Oliveiro wrote:
> On Thu, 3 Oct 2024 14:34:01 -0500, Lynn McGuire wrote:
>
>> My code used to assign Hollerith to Real numbers but I ripped that out
>> years ago in a project to get rid of Hollerith.
>
> Fortran was the first programming language I learned (from the Anna Burke
> Harris book). The only kind of string literals I can remember in that
> first learning were Hollerith literals. I liked the fact that they were
> unambiguous: because length was explicit up front, you could any
> characters you liked in them.
>
> Later I discovered that “normal” people preferred explicitly-delimited
> string literals.
>

Assuming 4 bytes to a word, I find
integer txthdr (7) /4hText, 4h hea, 4hder,, 4h wit, 4hh a ,
4hcomm, 4ha /
uglier than
integer txthdr (7) /'Text', ' hea', 'der,', ' wit', 'h a ',
'comm', 'a ' /
but not as friendly as
character*28 txthdr /'Text header, with a comma ' /

As to making all variables containing strings integer back before
Fortran 77, that was an insurance policy to prevent disasters such as:
integer init4 / 4hinit /
real text4
c
c snip
c
text4 = init4

[Lawrence D'Oliveiro]

On Fri, 4 Oct 2024 12:13:52 +0200, R Daneel Olivaw wrote:

> but not as friendly as
> character*28 txthdr /'Text header, with a comma ' /

With all these additions to Fortran, I keep wondering “when will they
finish reinventing PL/I?”. Because at an early point in the development of
PL/I, they were going to call it “FORTRAN VI”.

One PL/I feature still missing from Fortran is VARYING strings.

[Steven G. Kargl]

On Fri, 04 Oct 2024 20:04:05 +0000, Lawrence D'Oliveiro wrote:

> On Fri, 4 Oct 2024 12:13:52 +0200, R Daneel Olivaw wrote:
>
>> but not as friendly as
>> character*28 txthdr /'Text header, with a comma ' /
>
> With all these additions to Fortran, I keep wondering “when will they
> finish reinventing PL/I?”. Because at an early point in the development
> of PL/I, they were going to call it “FORTRAN VI”.
>
> One PL/I feature still missing from Fortran is VARYING strings.

The above line of code in not standard conforming Fortran.

--
steve

[R Daneel Olivaw]

Steven G. Kargl wrote:
> On Fri, 04 Oct 2024 20:04:05 +0000, Lawrence D'Oliveiro wrote:
>
>> On Fri, 4 Oct 2024 12:13:52 +0200, R Daneel Olivaw wrote:
>>
>>> but not as friendly as
>>> character*28 txthdr /'Text header, with a comma ' /
>>
>> With all these additions to Fortran, I keep wondering “when will they
>> finish reinventing PL/I?”. Because at an early point in the development
>> of PL/I, they were going to call it “FORTRAN VI”.
>>
>> One PL/I feature still missing from Fortran is VARYING strings.
>
> The above line of code in not standard conforming Fortran.
>

I have not fed it through the compiler I used to use (mainframe, and I
no longer have access) but that compiler conformed to Fortran77 to the
extent they did not even offer integer*8.
They did have some local extensions (statement functions) but they were
clearly marked as non-standard in the manuals.

[Steven G. Kargl]

On Sat, 05 Oct 2024 11:31:22 +0200, R Daneel Olivaw wrote:

> Steven G. Kargl wrote:
>> On Fri, 04 Oct 2024 20:04:05 +0000, Lawrence D'Oliveiro wrote:
>>
>>> On Fri, 4 Oct 2024 12:13:52 +0200, R Daneel Olivaw wrote:
>>>
>>>> but not as friendly as
>>>> character*28 txthdr /'Text header, with a comma ' /
>>>
>>> With all these additions to Fortran, I keep wondering “when will they
>>> finish reinventing PL/I?”. Because at an early point in the development
>>> of PL/I, they were going to call it “FORTRAN VI”.
>>>
>>> One PL/I feature still missing from Fortran is VARYING strings.
>>
>> The above line of code in not standard conforming Fortran.
>>
>
> I have not fed it through the compiler I used to use (mainframe, and I
> no longer have access) but that compiler conformed to Fortran77 to the
> extent they did not even offer integer*8.
> They did have some local extensions (statement functions) but they were
> clearly marked as non-standard in the manuals.

Yes, it was an extension. It is supported by gfortran.

% cat a.f90
program testprog
character*28 txthdr /'Text header, with a comma ' /
print *, txthdr
end program testprog

% gfcx -o z a.f90 && ./z
Text header, with a comma

% gfcx -o z -std=f2023 a.f90 && ./z
a.f90:2:25:

2 | character*28 txthdr /'Text header, with a comma ' /
| 1
Error: GNU Extension: Old-style initialization at (1)

--
steve

[Gary Scott]

On 10/4/2024 3:04 PM, Lawrence D'Oliveiro wrote:
> On Fri, 4 Oct 2024 12:13:52 +0200, R Daneel Olivaw wrote:
>
>> but not as friendly as
>> character*28 txthdr /'Text header, with a comma ' /
>
> With all these additions to Fortran, I keep wondering “when will they
> finish reinventing PL/I?”. Because at an early point in the development of
> PL/I, they were going to call it “FORTRAN VI”.
>
> One PL/I feature still missing from Fortran is VARYING strings.

Fortran does have a form of varying string...just not super convenient
to use in the general case.

[Clive Page]

On 04/10/2024 21:36, Gary Scott wrote:
> On 10/4/2024 3:04 PM, Lawrence D'Oliveiro wrote:
>> On Fri, 4 Oct 2024 12:13:52 +0200, R Daneel Olivaw wrote:
>>
>>> but not as friendly as
>>>         character*28 txthdr /'Text header, with a comma   ' /
>>
>> With all these additions to Fortran, I keep wondering “when will they
>> finish reinventing PL/I?”. Because at an early point in the development of
>> PL/I, they were going to call it “FORTRAN VI”.
>>
>> One PL/I feature still missing from Fortran is VARYING strings.
>
> Fortran does have a form of varying string...just not super convenient to use in the general case.


Yes but for practical purposes it only works for scalars, not arrays. Since nearly all the rest of Fortran is based on the (unstated, but widely-understood) principle that arrays are first-class objects, this is a real pity.

--
Clive Page

[Gary Scott]

On 10/5/2024 11:42 AM, Clive Page wrote:
> On 04/10/2024 21:36, Gary Scott wrote:
>> On 10/4/2024 3:04 PM, Lawrence D'Oliveiro wrote:
>>> On Fri, 4 Oct 2024 12:13:52 +0200, R Daneel Olivaw wrote:
>>>
>>>> but not as friendly as
>>>>         character*28 txthdr /'Text header, with a comma   ' /
>>>
>>> With all these additions to Fortran, I keep wondering “when will they
>>> finish reinventing PL/I?”. Because at an early point in the
>>> development of
>>> PL/I, they were going to call it “FORTRAN VI”.
>>>
>>> One PL/I feature still missing from Fortran is VARYING strings.
>>
>> Fortran does have a form of varying string...just not super convenient
>> to use in the general case.
>
>
> Yes but for practical purposes it only works for scalars, not arrays.
> Since nearly all the rest of Fortran is based on the (unstated, but
> widely-understood) principle that arrays are first-class objects, this
> is a real pity.
>
Yes. I've however never found the fixed length strings to be a major
hindrance. I know exactly how they work and have been able to
adequately mimic/store variable length strings within reasonably sized
fixed length buffers (various methods). I really liked the flexibility
of string/text processing of IBM's DCF/Script/GML. How that was
powerful string handling.

[Lawrence D'Oliveiro]

On Sat, 5 Oct 2024 13:52:01 -0500, Gary Scott wrote:

> I really liked the flexibility of string/text processing of IBM's
> DCF/Script/GML. How that was powerful string handling.

As good as Perl?

[Gary Scott]

On 10/5/2024 6:07 PM, Lawrence D'Oliveiro wrote:
> On Sat, 5 Oct 2024 13:52:01 -0500, Gary Scott wrote:
>
>> I really liked the flexibility of string/text processing of IBM's
>> DCF/Script/GML. How that was powerful string handling.
>
> As good as Perl?

vastly better, but it was specifically a text (document) processor,
vastly different purpose.

[Lawrence D'Oliveiro]

On Sat, 5 Oct 2024 19:39:31 -0500, Gary Scott wrote:

> On 10/5/2024 6:07 PM, Lawrence D'Oliveiro wrote:
>
>> On Sat, 5 Oct 2024 13:52:01 -0500, Gary Scott wrote:
>>
>>> I really liked the flexibility of string/text processing of IBM's
>>> DCF/Script/GML. How that was powerful string handling.
>>
>> As good as Perl?
>
> vastly better, but it was specifically a text (document) processor,
> vastly different purpose.

How could it have been better without regular expressions?

[Gary Scott]

On 10/5/2024 8:58 PM, Lawrence D'Oliveiro wrote:
> On Sat, 5 Oct 2024 19:39:31 -0500, Gary Scott wrote:
>
>> On 10/5/2024 6:07 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Sat, 5 Oct 2024 13:52:01 -0500, Gary Scott wrote:
>>>
>>>> I really liked the flexibility of string/text processing of IBM's
>>>> DCF/Script/GML. How that was powerful string handling.
>>>
>>> As good as Perl?
>>
>> vastly better, but it was specifically a text (document) processor,
>> vastly different purpose.
>
> How could it have been better without regular expressions?
Extremely powerful substitution, full control of fonts, code points,
code pages, dynamically controlled overprinting, image handling,
direct/binary datastream writing/editing, formatting page columns,
gutters, running headings/footings, tables, lists (order, unordered,
etc.), full support for foreign languages, double byte character sets
decades before unicode, programmed symbol sets to devices. Directly
define your own gml (predecessor to html) tags. Full support for
numerical conversions, special/math symbol support, character
substitution, font substitution tables based upon device
capabilities...just to scratch the surface...

[Lawrence D'Oliveiro]

On Sat, 5 Oct 2024 21:35:42 -0500, Gary Scott wrote:

> On 10/5/2024 8:58 PM, Lawrence D'Oliveiro wrote:
>
>> How could it have been better without regular expressions?
>
> Extremely powerful substitution ...

But without regular expressions, that kind of thing gets quite limited.

> full control of fonts, code points, code pages, dynamically controlled
> overprinting, image handling ...

troff was doing this sort of thing years before. Remember that the Unix
folks at Bell Labs got the funding to develop their new OS primarily on
the rationale that it would offer good text-processing facilities, like
you describe.

> direct/binary datastream writing/editing, formatting page columns,
> gutters, running headings/footings, tables, lists (order, unordered,
> etc.) ...

I notice no mention of line-numbering. That’s rather crucial for legal
documents -- another selling point that the Bell Labs folks were able to
address.

> ... full support for foreign languages, double byte character sets
> decades before unicode ...

I don’t know why you think that was such a radical feature, given that the
Koreans introduced their national double-byte code in 1974, the Japanese
theirs in 1978, and the Chinese did GB2312 in 1980.

> Directly define your own gml (predecessor to html) tags.

troff incorporated the idea of macros right from the beginning.

[Gary Scott]

On 10/5/2024 10:39 PM, Lawrence D'Oliveiro wrote:
> On Sat, 5 Oct 2024 21:35:42 -0500, Gary Scott wrote:
>
>> On 10/5/2024 8:58 PM, Lawrence D'Oliveiro wrote:
>>
>>> How could it have been better without regular expressions?
>>
>> Extremely powerful substitution ...
>
> But without regular expressions, that kind of thing gets quite limited.
>
>> full control of fonts, code points, code pages, dynamically controlled
>> overprinting, image handling ...
>
> troff was doing this sort of thing years before. Remember that the Unix
> folks at Bell Labs got the funding to develop their new OS primarily on
> the rationale that it would offer good text-processing facilities, like
> you describe.
>
>> direct/binary datastream writing/editing, formatting page columns,
>> gutters, running headings/footings, tables, lists (order, unordered,
>> etc.) ...
>
> I notice no mention of line-numbering. That’s rather crucial for legal
> documents -- another selling point that the Bell Labs folks were able to
> address.
>
>> ... full support for foreign languages, double byte character sets
>> decades before unicode ...
>
> I don’t know why you think that was such a radical feature, given that the
> Koreans introduced their national double-byte code in 1974, the Japanese
> theirs in 1978, and the Chinese did GB2312 in 1980.
>
>> Directly define your own gml (predecessor to html) tags.
>
> troff incorporated the idea of macros right from the beginning.

This stuff was done in the 60s and 70s, certainly it evolved over time.

[Gary Scott]

On 10/6/2024 10:18 AM, Gary Scott wrote:
> On 10/5/2024 10:39 PM, Lawrence D'Oliveiro wrote:
>> On Sat, 5 Oct 2024 21:35:42 -0500, Gary Scott wrote:
>>
>>> On 10/5/2024 8:58 PM, Lawrence D'Oliveiro wrote:
>>>
>>>> How could it have been better without regular expressions?
>>>
>>> Extremely powerful substitution ...
>>
>> But without regular expressions, that kind of thing gets quite limited.
>>
>>> full control of fonts, code points, code pages, dynamically controlled
>>> overprinting, image handling ...
>>
>> troff was doing this sort of thing years before. Remember that the Unix
>> folks at Bell Labs got the funding to develop their new OS primarily on
>> the rationale that it would offer good text-processing facilities, like
>> you describe.
>>
>>> direct/binary datastream writing/editing, formatting page columns,
>>> gutters, running headings/footings, tables, lists (order, unordered,
>>> etc.) ...
>>
>> I notice no mention of line-numbering. That’s rather crucial for legal
>> documents -- another selling point that the Bell Labs folks were able to
>> address.
>>
>>> ... full support for foreign languages, double byte character sets
>>> decades before unicode ...
>>
>> I don’t know why you think that was such a radical feature, given that
>> the
>> Koreans introduced their national double-byte code in 1974, the Japanese
>> theirs in 1978, and the Chinese did GB2312 in 1980.
>>
>>> Directly define your own gml (predecessor to html) tags.
>>
>> troff incorporated the idea of macros right from the beginning.
>
> This stuff was done in the 60s and 70s, certainly it evolved over time.
And yes it supported line numbers and change markups.

[Lynn McGuire]

On 10/1/2024 9:58 PM, Lynn McGuire wrote:
> I need many of my integers to be integer*8 in my port to 64 bit.  In C/
> C++ code, I can say 123456L to mean a long long value, generally 64
> bit.  Is there a corresponding way to do this in Fortran or am I stuck
> with:
>
>     call xyz (1)
>
>     subroutine xyz (ivalue)
>     integer*8 ivalue
>     ...
>     return end
>
> must be:
>
>     integer*8 ivalue
>     ...
>     ivalue = 1
>     call xyz (ivalue)
>
> Thanks,
> Lynn

Thanks to all for their several solutions !

Lynn