Does know if anyone updated f2c to convert Fortran data structures to C
data structures ?
https://www.netlib.org/f2c/

I am contemplating using a modified f2c to convert our 850,000 lines of
F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.

I asked the Netlib maintainer and he does not know of any.

Thanks,
Lynn

On Thursday, May 26, 2022 at 2:35:21 PM UTC-7, Lynn McGuire wrote:
> Does know if anyone updated f2c to convert Fortran data structures to C
> data structures ?
> https://www.netlib.org/f2c/

Since f2c is supposed to be Fortran 77, it wouldn't have structures.

I do remember that some DEC compilers might have had them.

As far as I know, f2c doesn't make readable C code. With some work,
you might get it to do more like what you want to see.

On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
> Does know if anyone updated f2c to convert Fortran data structures to C
> data structures ?
> https://www.netlib.org/f2c/
>
> I am contemplating using a modified f2c to convert our 850,000 lines of
> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.

The F77 code would be better updated to F90 or later form.

Silverfrost f95 can do it as part of the compilation process.
However, it does not transcribe the comments.

On Thursday, May 26, 2022 at 5:35:21 PM UTC-4, Lynn McGuire wrote:
> Does know if anyone updated f2c to convert Fortran data structures to C
> data structures ?
> https://www.netlib.org/f2c/
>
> I am contemplating using a modified f2c to convert our 850,000 lines of
> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
>
> I asked the Netlib maintainer and he does not know of any.
>
> Thanks,
> Lynn

As I have tweeted https://github.com/Beliavsky/FortranTip/blob/main/topics.md,

Use the bind(c) attribute to make a derived type compatible with C, with restrictions listed at https://gcc.gnu.org/onlinedocs/gfortran/Derived-Types-and-struct.html. For example,

type, bind(c) :: date
integer (kind=c_int) :: year, month
end type

interoperates with

typedef struct {
int year, month;
} date;

On 5/27/2022 3:19 AM, Robin Vowels wrote:
> On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
>> Does know if anyone updated f2c to convert Fortran data structures to C
>> data structures ?
>> https://www.netlib.org/f2c/
>>
>> I am contemplating using a modified f2c to convert our 850,000 lines of
>> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
>
> The F77 code would be better updated to F90 or later form.
>
> Silverfrost f95 can do it as part of the compilation process.
> However, it does not transcribe the comments.

Please, you are making massive assumptions about my environment.

Lynn

On Thursday, May 26, 2022 at 4:35:21 PM UTC-5, Lynn McGuire wrote:
> Does know if anyone updated f2c to convert Fortran data structures to C
> data structures ?
> https://www.netlib.org/f2c/
>
> I am contemplating using a modified f2c to convert our 850,000 lines of
> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
>
> I asked the Netlib maintainer and he does not know of any.
>
> Thanks,
> Lynn

This is how f2c is described by its own authors:

"The converter f2c is a copy of the f77 Fortran compiler which has been altered to print out a C representation of the program being converted. The program f2c is a horror, based on ancient code and hacked unmercifully. Users are only supposed to look at its C output, not at its appalling inner workings."

If your 850,000 lines of F77 use nonstandard extensions of Fortran 77 such as DEC structures, unions, Cray pointers, etc., I suggest that you consider something other than f2c.

On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
> On 5/27/2022 3:19 AM, Robin Vowels wrote:
> > On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
> >> Does know if anyone updated f2c to convert Fortran data structures to C
> >> data structures ?
> >> https://www.netlib.org/f2c/
> >>
> >> I am contemplating using a modified f2c to convert our 850,000 lines of
> >> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
> >
> > The F77 code would be better updated to F90 or later form.
> >
> > Silverfrost f95 can do it as part of the compilation process.
> > However, it does not transcribe the comments.
..
> Please, you are making massive assumptions about my environment.
..
Is this the project that for years you have been saying that you
want to convert to modern Fortran ?
..
I have had considerable experience in converting F77 and earlier
to F90+ and other languages,
In the process, I uncovered numbers of bugs in the F77 and
earlier sources.
..
Converting your 850,000 lines of code to F90 would be a
massive enough job of itself, let alone to a completely
different language.
..
That's why I suggested updating the code to F90 or later.

On 5/30/2022 8:15 AM, Robin Vowels wrote:
> On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
>> On 5/27/2022 3:19 AM, Robin Vowels wrote:
>>> On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
>>>> Does know if anyone updated f2c to convert Fortran data structures to C
>>>> data structures ?
>>>> https://www.netlib.org/f2c/
>>>>
>>>> I am contemplating using a modified f2c to convert our 850,000 lines of
>>>> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
>>>
>>> The F77 code would be better updated to F90 or later form.
>>>
>>> Silverfrost f95 can do it as part of the compilation process.
>>> However, it does not transcribe the comments.
> .
>> Please, you are making massive assumptions about my environment.
> .
> Is this the project that for years you have been saying that you
> want to convert to modern Fortran ?
> .
> I have had considerable experience in converting F77 and earlier
> to F90+ and other languages,
> In the process, I uncovered numbers of bugs in the F77 and
> earlier sources.
> .
> Converting your 850,000 lines of code to F90 would be a
> massive enough job of itself, let alone to a completely
> different language.
> .
> That's why I suggested updating the code to F90 or later.

Yes. I have changed my mind. I am going to convert my Fortran
structures to an equivalenced double precision array and a integer*8
array (like I used to have from 1977 to 2002, only an equivalenced
single real array and integer*4 array). Then I am going to start
running my modified f2c on it. F2c already converts integer*8 to a long
long int.

I have been running extensive tests on f2c. The generated c code is
very good about converting the algorithms across the language barrier.
And the code is good (there is one array bug though). The translated
read and write code is freaking horrible so I've got to make it better.
Which, people have already noted and worked on.
https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c

BTW, my calculation engine is already about 10% C++ code. You cannot do
OLE2 in Fortran and my ZIP code is so highly tied to C bit twiddling. I
use extensive C++ glue code for manipulating embedded Excel spreadsheets
in my calculation engine and allowing my users to embed my calculation
engine in their VB, VBA (Excel VB), and C++ code.

Thanks,
Lynn

On Tuesday, May 31, 2022 at 12:07:43 AM UTC-4, Lynn McGuire wrote:
> On 5/30/2022 8:15 AM, Robin Vowels wrote:
> > On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
> >> On 5/27/2022 3:19 AM, Robin Vowels wrote:
> >>> On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
> >>>> Does know if anyone updated f2c to convert Fortran data structures to C
> >>>> data structures ?
> >>>> https://www.netlib.org/f2c/
> >>>>
> >>>> I am contemplating using a modified f2c to convert our 850,000 lines of
> >>>> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
> >>>
> >>> The F77 code would be better updated to F90 or later form.
> >>>
> >>> Silverfrost f95 can do it as part of the compilation process.
> >>> However, it does not transcribe the comments.
> > .
> >> Please, you are making massive assumptions about my environment.
> > .
> > Is this the project that for years you have been saying that you
> > want to convert to modern Fortran ?
> > .
> > I have had considerable experience in converting F77 and earlier
> > to F90+ and other languages,
> > In the process, I uncovered numbers of bugs in the F77 and
> > earlier sources.
....
> Which, people have already noted and worked on.
>
> https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c
>
This URL includes a link to the improved f2c:

http://www.nag.co.uk:70/1h/public

but that link is dead. Does anyone know of an alternative source?

Daniel Feenberg

On 5/30/2022 11:07 PM, Lynn McGuire wrote:
> On 5/30/2022 8:15 AM, Robin Vowels wrote:
>> On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
>>> On 5/27/2022 3:19 AM, Robin Vowels wrote:
>>>> On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
>>>>> Does know if anyone updated f2c to convert Fortran data structures
>>>>> to C
>>>>> data structures ?
>>>>> https://www.netlib.org/f2c/
>>>>>
>>>>> I am contemplating using a modified f2c to convert our 850,000
>>>>> lines of
>>>>> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my
>>>>> needs.
>>>>
>>>> The F77 code would be better updated to F90 or later form.
>>>>
>>>> Silverfrost f95 can do it as part of the compilation process.
>>>> However, it does not transcribe the comments.
>> .
>>> Please, you are making massive assumptions about my environment.
>> .
>> Is this the project that for years you have been saying that you
>> want to convert  to modern Fortran ?
>> .
>> I have had considerable experience in converting F77 and earlier
>> to F90+ and other languages,
>> In the process, I uncovered numbers of bugs in the F77 and
>> earlier sources.
>> .
>> Converting your 850,000 lines of code to F90 would be a
>> massive enough job of itself, let alone to a completely
>> different language.
>> .
>> That's why I suggested updating the code to F90 or later.
>
> Yes.  I have changed my mind.  I am going to convert my Fortran
> structures to an equivalenced double precision array and a integer*8
> array (like I used to have from 1977 to 2002, only an equivalenced
> single real array and integer*4 array).  Then I am going to start
> running my modified f2c on it.  F2c already converts integer*8 to a long
> long int.
>
> I have been running extensive tests on f2c.  The generated c code is
> very good about converting the algorithms across the language barrier.
> And the code is good (there is one array bug though).  The translated
> read and write code is freaking horrible so I've got to make it better.
>  Which, people have already noted and worked on.
>
> https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c
>
>
> BTW, my calculation engine is already about 10% C++ code.  You cannot do
> OLE2 in Fortran and my ZIP code is so highly tied to C bit twiddling.  I
> use extensive C++ glue code for manipulating embedded Excel spreadsheets
> in my calculation engine and allowing my users to embed my calculation
> engine in their VB, VBA (Excel VB), and C++ code.
>
> Thanks,
> Lynn

I used DDE, OLE, OLE2, COM from Fortran for decades.

On 5/31/2022 9:40 AM, Gary Scott wrote:
> On 5/30/2022 11:07 PM, Lynn McGuire wrote:
>> On 5/30/2022 8:15 AM, Robin Vowels wrote:
>>> On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
>>>> On 5/27/2022 3:19 AM, Robin Vowels wrote:
>>>>> On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
>>>>>> Does know if anyone updated f2c to convert Fortran data structures
>>>>>> to C
>>>>>> data structures ?
>>>>>> https://www.netlib.org/f2c/
>>>>>>
>>>>>> I am contemplating using a modified f2c to convert our 850,000
>>>>>> lines of
>>>>>> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my
>>>>>> needs.
>>>>>
>>>>> The F77 code would be better updated to F90 or later form.
>>>>>
>>>>> Silverfrost f95 can do it as part of the compilation process.
>>>>> However, it does not transcribe the comments.
>>> .
>>>> Please, you are making massive assumptions about my environment.
>>> .
>>> Is this the project that for years you have been saying that you
>>> want to convert  to modern Fortran ?
>>> .
>>> I have had considerable experience in converting F77 and earlier
>>> to F90+ and other languages,
>>> In the process, I uncovered numbers of bugs in the F77 and
>>> earlier sources.
>>> .
>>> Converting your 850,000 lines of code to F90 would be a
>>> massive enough job of itself, let alone to a completely
>>> different language.
>>> .
>>> That's why I suggested updating the code to F90 or later.
>>
>> Yes.  I have changed my mind.  I am going to convert my Fortran
>> structures to an equivalenced double precision array and a integer*8
>> array (like I used to have from 1977 to 2002, only an equivalenced
>> single real array and integer*4 array).  Then I am going to start
>> running my modified f2c on it.  F2c already converts integer*8 to a
>> long long int.
>>
>> I have been running extensive tests on f2c.  The generated c code is
>> very good about converting the algorithms across the language barrier.
>> And the code is good (there is one array bug though).  The translated
>> read and write code is freaking horrible so I've got to make it
>> better.   Which, people have already noted and worked on.
>>
>> https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c
>>
>>
>> BTW, my calculation engine is already about 10% C++ code.  You cannot
>> do OLE2 in Fortran and my ZIP code is so highly tied to C bit
>> twiddling.  I use extensive C++ glue code for manipulating embedded
>> Excel spreadsheets in my calculation engine and allowing my users to
>> embed my calculation engine in their VB, VBA (Excel VB), and C++ code.
>>
>> Thanks,
>> Lynn
>
> I used DDE, OLE, OLE2, COM from Fortran for decades.

Sounds like you are better programmer than me. How did you do the wide
character strings in OLE2 ?

Lynn

On 5/31/2022 6:30 AM, Daniel Feenberg wrote:
> On Tuesday, May 31, 2022 at 12:07:43 AM UTC-4, Lynn McGuire wrote:
>> On 5/30/2022 8:15 AM, Robin Vowels wrote:
>>> On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
>>>> On 5/27/2022 3:19 AM, Robin Vowels wrote:
>>>>> On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
>>>>>> Does know if anyone updated f2c to convert Fortran data structures to C
>>>>>> data structures ?
>>>>>> https://www.netlib.org/f2c/
>>>>>>
>>>>>> I am contemplating using a modified f2c to convert our 850,000 lines of
>>>>>> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
>>>>>
>>>>> The F77 code would be better updated to F90 or later form.
>>>>>
>>>>> Silverfrost f95 can do it as part of the compilation process.
>>>>> However, it does not transcribe the comments.
>>> .
>>>> Please, you are making massive assumptions about my environment.
>>> .
>>> Is this the project that for years you have been saying that you
>>> want to convert to modern Fortran ?
>>> .
>>> I have had considerable experience in converting F77 and earlier
>>> to F90+ and other languages,
>>> In the process, I uncovered numbers of bugs in the F77 and
>>> earlier sources.
> ...
>> Which, people have already noted and worked on.
>>
>> https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c
>>
> This URL includes a link to the improved f2c:
>
> http://www.nag.co.uk:70/1h/public
>
> but that link is dead. Does anyone know of an alternative source?
>
> Daniel Feenberg

I contacted NAG and they do not have the code anymore. Or they
incorporated it into their Fortran compiler. They were not sure. I did
not talk with the writer of the article though.

I did see something somewhat similar in Koenig's ??? Toolbox but I need
to investigate it further:
https://www.ibiblio.org/pub/Linux/devel/lang/fortran/!INDEX.short.html

Thanks,
Lynn

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

> I did see something somewhat similar in Koenig's ??? Toolbox but I need
> to investigate it further:
> https://www.ibiblio.org/pub/Linux/devel/lang/fortran/!INDEX.short.html

Certainly not mine, I just ported the source to Linux (from a
HP-UX version) after having had good experience with it on MVS.
It originally came from NAG, I believe.

Toolpack has some nice restructuring features, but is _very_ picky
about strict F77 compliance. It does not even grok IMPLICIT NONE,
for example.

Regarding f2c - I just checked it on my Ubuntu system, and at least
I/O is broken there, something wrong with the library, I suppose.

I am also not sure if the games it plays for array dummy arguments
generate valid C or not. If you look at

subroutine foo(x,n)
dimension x(n)
x(1) = 1.
end

this gets translated to

/* Subroutine */ int foo_(real *x, integer *n)
{ /* Parameter adjustments */
--x;

/* Function Body */
x[1] = 1.f;
return 0;
} /* foo_ */

but for this another forum wold be more appropriate.

On Tuesday, May 31, 2022 at 1:02:50 PM UTC-7, Thomas Koenig wrote:

(snip)

> Regarding f2c - I just checked it on my Ubuntu system, and at least
> I/O is broken there, something wrong with the library, I suppose.
>
> I am also not sure if the games it plays for array dummy arguments
> generate valid C or not. If you look at
>
> subroutine foo(x,n)
> dimension x(n)
> x(1) = 1.
> end
> this gets translated to
> /* Subroutine */ int foo_(real *x, integer *n)
> {
> /* Parameter adjustments */
> --x;
> /* Function Body */
> x[1] = 1.f;
> return 0;
> } /* foo_ */
> but for this another forum wold be more appropriate.

This question came up often regarding "Numerical Recipes in C".

The reason it comes up at all in C, is there is no guarantee
that x-1 < x. If you require that, you have to be careful.

C guarantees that x+1 > x for x pointing to an actual variable
or array element, but not that x-1 < x. Don't, for example:

for(x=a+9; x>=a, x--) printf("%s", *x);

On 5/31/2022 3:02 PM, Thomas Koenig wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>
>> I did see something somewhat similar in Koenig's ??? Toolbox but I need
>> to investigate it further:
>> https://www.ibiblio.org/pub/Linux/devel/lang/fortran/!INDEX.short.html
>
> Certainly not mine, I just ported the source to Linux (from a
> HP-UX version) after having had good experience with it on MVS.
> It originally came from NAG, I believe.
>
> Toolpack has some nice restructuring features, but is _very_ picky
> about strict F77 compliance. It does not even grok IMPLICIT NONE,
> for example.
>
> Regarding f2c - I just checked it on my Ubuntu system, and at least
> I/O is broken there, something wrong with the library, I suppose.
>
> I am also not sure if the games it plays for array dummy arguments
> generate valid C or not. If you look at
>
> subroutine foo(x,n)
> dimension x(n)
> x(1) = 1.
> end
>
> this gets translated to
>
> /* Subroutine */ int foo_(real *x, integer *n)
> {
> /* Parameter adjustments */
> --x;
>
> /* Function Body */
> x[1] = 1.f;
> return 0;
> } /* foo_ */
>
> but for this another forum wold be more appropriate.

That is valid C code and a valid pointer. But we do not like it so we
are going to rip out the --x parameter adjustment and subtract 1 from
the argument array addressing like f2c does for local arrays. That
means that we will not be able to modify portions of our F77 but all of
it at once.

Thanks,
Lynn

Lynn

On 5/31/2022 1:12 PM, Lynn McGuire wrote:
> On 5/31/2022 9:40 AM, Gary Scott wrote:
>> On 5/30/2022 11:07 PM, Lynn McGuire wrote:
>>> On 5/30/2022 8:15 AM, Robin Vowels wrote:
>>>> On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
>>>>> On 5/27/2022 3:19 AM, Robin Vowels wrote:
>>>>>> On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
>>>>>>> Does know if anyone updated f2c to convert Fortran data
>>>>>>> structures to C
>>>>>>> data structures ?
>>>>>>> https://www.netlib.org/f2c/
>>>>>>>
>>>>>>> I am contemplating using a modified f2c to convert our 850,000
>>>>>>> lines of
>>>>>>> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet
>>>>>>> my needs.
>>>>>>
>>>>>> The F77 code would be better updated to F90 or later form.
>>>>>>
>>>>>> Silverfrost f95 can do it as part of the compilation process.
>>>>>> However, it does not transcribe the comments.
>>>> .
>>>>> Please, you are making massive assumptions about my environment.
>>>> .
>>>> Is this the project that for years you have been saying that you
>>>> want to convert  to modern Fortran ?
>>>> .
>>>> I have had considerable experience in converting F77 and earlier
>>>> to F90+ and other languages,
>>>> In the process, I uncovered numbers of bugs in the F77 and
>>>> earlier sources.
>>>> .
>>>> Converting your 850,000 lines of code to F90 would be a
>>>> massive enough job of itself, let alone to a completely
>>>> different language.
>>>> .
>>>> That's why I suggested updating the code to F90 or later.
>>>
>>> Yes.  I have changed my mind.  I am going to convert my Fortran
>>> structures to an equivalenced double precision array and a integer*8
>>> array (like I used to have from 1977 to 2002, only an equivalenced
>>> single real array and integer*4 array).  Then I am going to start
>>> running my modified f2c on it.  F2c already converts integer*8 to a
>>> long long int.
>>>
>>> I have been running extensive tests on f2c.  The generated c code is
>>> very good about converting the algorithms across the language
>>> barrier. And the code is good (there is one array bug though).  The
>>> translated read and write code is freaking horrible so I've got to
>>> make it better.   Which, people have already noted and worked on.
>>>
>>> https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c
>>>
>>>
>>> BTW, my calculation engine is already about 10% C++ code.  You cannot
>>> do OLE2 in Fortran and my ZIP code is so highly tied to C bit
>>> twiddling.  I use extensive C++ glue code for manipulating embedded
>>> Excel spreadsheets in my calculation engine and allowing my users to
>>> embed my calculation engine in their VB, VBA (Excel VB), and C++ code.
>>>
>>> Thanks,
>>> Lynn
>>
>> I used DDE, OLE, OLE2, COM from Fortran for decades.
>
> Sounds like you are better programmer than me.  How did you do the wide
> character strings in OLE2 ?
>
> Lynn
Structures and various operating system APIs allow interoperability. I
generally wrote simpler internal APIs to call from Fortran that did the
hard work and made it easier to use.

On 5/31/22 5:04 PM, Lynn McGuire wrote:
[...]
>> I am also not sure if the games it plays for array dummy arguments
>> generate valid C or not.  If you look at
>>
>>        subroutine foo(x,n)
>>        dimension x(n)
>>        x(1) = 1.
>>        end
>>
>> this gets translated to
>>
>> /* Subroutine */ int foo_(real *x, integer *n)
>> {
>>      /* Parameter adjustments */
>>      --x;
>>
>>      /* Function Body */
>>      x[1] = 1.f;
>>      return 0;
>> } /* foo_ */
>>
>> but for this another forum wold be more appropriate.
>
> That is valid C code and a valid pointer.
[...]

Others have already stated how it violates the C standard. The reason
for this restriction in C was that the array concept was based on a
segmented memory model. If the first element of the array happened to be
at a segment boundary, then decrementing the pointer meant that the
address was no longer necessarily even within the program's address
space. Depending on the OS, it could be pointing at some part of the OS,
or in a multitasking environment to the memory of another process. Then
later when virtual memory became popular, it could have resulted in page
address violations, depending on how exactly the virtual and actual
memory were mapped to each other. Such address computations could
trigger errors, even if the pointers were never referenced. The upper
range of the pointers were accounted for in the language. I think the
restriction was that the pointer was allowed to go one unit outside of
the array bound, but it could not be dereferenced once it was there.
There was no such allowance for the lower bound of the array, the
language simply did not allow the pointer outside that range, whether or
not it was later referenced or, as in the above example, incremented
back to within the valid array range.

$.02 -Ron Shepard

On 6/1/2022 9:13 AM, Gary Scott wrote:
> On 5/31/2022 1:12 PM, Lynn McGuire wrote:
>> On 5/31/2022 9:40 AM, Gary Scott wrote:
>>> On 5/30/2022 11:07 PM, Lynn McGuire wrote:
>>>> On 5/30/2022 8:15 AM, Robin Vowels wrote:
>>>>> On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
>>>>>> On 5/27/2022 3:19 AM, Robin Vowels wrote:
>>>>>>> On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
>>>>>>>> Does know if anyone updated f2c to convert Fortran data
>>>>>>>> structures to C
>>>>>>>> data structures ?
>>>>>>>> https://www.netlib.org/f2c/
>>>>>>>>
>>>>>>>> I am contemplating using a modified f2c to convert our 850,000
>>>>>>>> lines of
>>>>>>>> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet
>>>>>>>> my needs.
>>>>>>>
>>>>>>> The F77 code would be better updated to F90 or later form.
>>>>>>>
>>>>>>> Silverfrost f95 can do it as part of the compilation process.
>>>>>>> However, it does not transcribe the comments.
>>>>> .
>>>>>> Please, you are making massive assumptions about my environment.
>>>>> .
>>>>> Is this the project that for years you have been saying that you
>>>>> want to convert  to modern Fortran ?
>>>>> .
>>>>> I have had considerable experience in converting F77 and earlier
>>>>> to F90+ and other languages,
>>>>> In the process, I uncovered numbers of bugs in the F77 and
>>>>> earlier sources.
>>>>> .
>>>>> Converting your 850,000 lines of code to F90 would be a
>>>>> massive enough job of itself, let alone to a completely
>>>>> different language.
>>>>> .
>>>>> That's why I suggested updating the code to F90 or later.
>>>>
>>>> Yes.  I have changed my mind.  I am going to convert my Fortran
>>>> structures to an equivalenced double precision array and a integer*8
>>>> array (like I used to have from 1977 to 2002, only an equivalenced
>>>> single real array and integer*4 array).  Then I am going to start
>>>> running my modified f2c on it.  F2c already converts integer*8 to a
>>>> long long int.
>>>>
>>>> I have been running extensive tests on f2c.  The generated c code is
>>>> very good about converting the algorithms across the language
>>>> barrier. And the code is good (there is one array bug though).  The
>>>> translated read and write code is freaking horrible so I've got to
>>>> make it better.   Which, people have already noted and worked on.
>>>>
>>>> https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c
>>>>
>>>>
>>>> BTW, my calculation engine is already about 10% C++ code.  You
>>>> cannot do OLE2 in Fortran and my ZIP code is so highly tied to C bit
>>>> twiddling.  I use extensive C++ glue code for manipulating embedded
>>>> Excel spreadsheets in my calculation engine and allowing my users to
>>>> embed my calculation engine in their VB, VBA (Excel VB), and C++ code.
>>>>
>>>> Thanks,
>>>> Lynn
>>>
>>> I used DDE, OLE, OLE2, COM from Fortran for decades.
>>
>> Sounds like you are better programmer than me.  How did you do the
>> wide character strings in OLE2 ?
>>
>> Lynn
> Structures and various operating system APIs allow interoperability.  I
> generally wrote simpler internal APIs to call from Fortran that did the
> hard work and made it easier to use.

Yes. I updated my Fortran code to call my OLE2 C++ code from my Win32
user interface when I needed to have two way discussions between my
calculation engine and Microsoft Excel.

Lynn

On 6/1/2022 10:24 AM, Ron Shepard wrote:
> On 5/31/22 5:04 PM, Lynn McGuire wrote:
> [...]
>>> I am also not sure if the games it plays for array dummy arguments
>>> generate valid C or not.  If you look at
>>>
>>>        subroutine foo(x,n)
>>>        dimension x(n)
>>>        x(1) = 1.
>>>        end
>>>
>>> this gets translated to
>>>
>>> /* Subroutine */ int foo_(real *x, integer *n)
>>> {
>>>      /* Parameter adjustments */
>>>      --x;
>>>
>>>      /* Function Body */
>>>      x[1] = 1.f;
>>>      return 0;
>>> } /* foo_ */
>>>
>>> but for this another forum wold be more appropriate.
>>
>> That is valid C code and a valid pointer.
> [...]
>
> Others have already stated how it violates the C standard. The reason
> for this restriction in C was that the array concept was based on a
> segmented memory model. If the first element of the array happened to be
> at a segment boundary, then decrementing the pointer meant that the
> address was no longer necessarily even within the program's address
> space. Depending on the OS, it could be pointing at some part of the OS,
> or in a multitasking environment to the memory of another process. Then
> later when virtual memory became popular, it could have resulted in page
> address violations, depending on how exactly the virtual and actual
> memory were mapped to each other. Such address computations could
> trigger errors, even if the pointers were never referenced. The upper
> range of the pointers were accounted for in the language. I think the
> restriction was that the pointer was allowed to go one unit outside of
> the array bound, but it could not be dereferenced once it was there.
> There was no such allowance for the lower bound of the array, the
> language simply did not allow the pointer outside that range, whether or
> not it was later referenced or, as in the above example, incremented
> back to within the valid array range.
>
> $.02 -Ron Shepard

Yes, very true. I am so used to programming in flat address planes now
that I don't even think about the good old days with segment pointers,
etc. Hopefully, we will never go back to those. After all, I am
starting the journey to 64 bit now.

Lynn

On Wednesday, June 1, 2022 at 8:24:36 AM UTC-7, Ron Shepard wrote:

(snip)

> Others have already stated how it violates the C standard. The reason
> for this restriction in C was that the array concept was based on a
> segmented memory model.

Well, even more than segmented, there used to be machines with
a tagged memory model. Each location had tags as to what kind
of value was stored there.

> If the first element of the array happened to be
> at a segment boundary, then decrementing the pointer meant that the
> address was no longer necessarily even within the program's address
> space.

Well, this could happen even without segmented memory, if the
array happened to be at the bottom of memory.

(To get back to the topic of this group, early Fortran compilers
allocated memory from the top of the address space down. Arrays
were stored in decreasing addresses in memory.)

In any case, yes, with protected mode x86, you can't load a segment
selector that doesn't select a valid segment descriptor, except for
the null selector, 0. In large model, though, only the offset is changed
with pointer arithmetic. In huge model, it will also change the
segment number. Even so, though, compilers usually won't load a
selector until you actually reference it, mostly because of code
like that. C guarantees that you can have a pointer to one past the
end of an array, and, more specifically, that it compares greater
than pointers into the array. That allows for loop tests based
on pointer values. Also, C doesn't allow (or doesn't define the
effect of) comparing pointers to different data items.

In the 80286 days, I was running OS/2 1.0 or 1.2, and allocating
segment selectors directly from the OS, with the exact length.
It was, then, a hardware exception even reading an array element
outside the array, and with no extra overhead. Very good for debugging
programs that might not be so good with array references.

> Depending on the OS, it could be pointing at some part of the OS,
> or in a multitasking environment to the memory of another process. Then
> later when virtual memory became popular, it could have resulted in page
> address violations, depending on how exactly the virtual and actual
> memory were mapped to each other.

Protected mode x86 is based on segments with a selector
and length. But as above, compilers would avoid unneeded
selector access to avoid the problem.

> Such address computations could
> trigger errors, even if the pointers were never referenced. The upper
> range of the pointers were accounted for in the language. I think the
> restriction was that the pointer was allowed to go one unit outside of
> the array bound, but it could not be dereferenced once it was there.

Yes. And so one less than the addressable space.

> There was no such allowance for the lower bound of the array, the
> language simply did not allow the pointer outside that range, whether or
> not it was later referenced or, as in the above example, incremented
> back to within the valid array range.

As above, compilers were good at avoiding that, but even so it can
still cause problems. Large model 16 bit x86 code only changes the offset,
and for other than equality and inequality, only compares the offset.
Even though it doesn't generate any access problems, the comparison
can fail.

On Wednesday, June 1, 2022 at 11:07:16 AM UTC-7, Lynn McGuire wrote:

(snip)

> Yes, very true. I am so used to programming in flat address planes now
> that I don't even think about the good old days with segment pointers,
> etc. Hopefully, we will never go back to those. After all, I am
> starting the journey to 64 bit now.

Reminds me, not so long ago I was working on a Fortran program
from the Fortran 66 days. There was then, and still isn't, short circuit
evaluation for logical expressions. This program had lots of

IF(J.LE.100 .AND. X(J).NE.0) ...

(for example) testing the array subscript and testing an array
value in the same IF statement. With many memory models,
that isn't much of a problem, especially if J stays close to the
ends of the array. However, it fails if bounds check is on.

I wanted to check the program for actual bounds errors,
and so had to change a lot of those!

gah4 <gah4@u.washington.edu> schrieb:

> Reminds me, not so long ago I was working on a Fortran program
> from the Fortran 66 days. There was then, and still isn't, short circuit
> evaluation for logical expressions. This program had lots of
>
> IF(J.LE.100 .AND. X(J).NE.0) ...
>
> (for example) testing the array subscript and testing an array
> value in the same IF statement. With many memory models,
> that isn't much of a problem, especially if J stays close to the
> ends of the array. However, it fails if bounds check is on.
>
> I wanted to check the program for actual bounds errors,
> and so had to change a lot of those!

A bit more problematic:

if (x .ne. 0. .and. y/x > 123.) then

....

Conditional expressions in Fortran will make it possible to
rewrite this as (hope I get this right)

if (( .not. x /= 0 ? .false. : y/x > 123.))

but the advantage of readability over

if (x .ne. 0) then
if (x/y > 123.) then

is certainly up for debate.

On Wednesday, June 1, 2022 at 4:19:26 PM UTC-4, Thomas Koenig wrote:
> gah4 <ga...@u.washington.edu> schrieb:
> > Reminds me, not so long ago I was working on a Fortran program
> > from the Fortran 66 days. There was then, and still isn't, short circuit
> > evaluation for logical expressions. This program had lots of
> >
> > IF(J.LE.100 .AND. X(J).NE.0) ...
> >
> > (for example) testing the array subscript and testing an array
> > value in the same IF statement. With many memory models,
> > that isn't much of a problem, especially if J stays close to the
> > ends of the array. However, it fails if bounds check is on.
> >
> > I wanted to check the program for actual bounds errors,
> > and so had to change a lot of those!
> A bit more problematic:
>
> if (x .ne. 0. .and. y/x > 123.) then
>
> ...
>
> Conditional expressions in Fortran will make it possible to
> rewrite this as (hope I get this right)
>
> if (( .not. x /= 0 ? .false. : y/x > 123.))
>
> but the advantage of readability over
>
> if (x .ne. 0) then
> if (x/y > 123.) then
>
> is certainly up for debate.

I have wondered why certain statements are not allowed after the test
in the Fortran one-line if statement. Often I want to write something like

if (i > 0) if (x(i) > 0.0) print*,"i, x(i)=",i,x(i)

On Wednesday, June 1, 2022 at 6:31:17 PM UTC-7, Beliavsky wrote:

(snip)

> I have wondered why certain statements are not allowed after the test
> in the Fortran one-line if statement. Often I want to write something like
> if (i > 0) if (x(i) > 0.0) print*,"i, x(i)=",i,x(i)

As far as I know, it goes back to Fortran 66, and wasn't changed since.

In Fortran 66 days, compilers had to fit in small amounts of memory on
many machines, so some features were kept out.

Yes, I would have liked that.

On Thursday, June 2, 2022 at 11:31:17 AM UTC+10, Beliavsky wrote:
> On Wednesday, June 1, 2022 at 4:19:26 PM UTC-4, Thomas Koenig wrote:
> > gah4 <ga...@u.washington.edu> schrieb:
> > > Reminds me, not so long ago I was working on a Fortran program
> > > from the Fortran 66 days. There was then, and still isn't, short circuit
> > > evaluation for logical expressions. This program had lots of
> > >
> > > IF(J.LE.100 .AND. X(J).NE.0) ...
> > >
> > > (for example) testing the array subscript and testing an array
> > > value in the same IF statement. With many memory models,
> > > that isn't much of a problem, especially if J stays close to the
> > > ends of the array. However, it fails if bounds check is on.
> > >
> > > I wanted to check the program for actual bounds errors,
> > > and so had to change a lot of those!
> > A bit more problematic:
> >
> > if (x .ne. 0. .and. y/x > 123.) then
> >
> > ...
> >
> > Conditional expressions in Fortran will make it possible to
> > rewrite this as (hope I get this right)
> >
> > if (( .not. x /= 0 ? .false. : y/x > 123.))
> >
> > but the advantage of readability over
> >
> > if (x .ne. 0) then
> > if (x/y > 123.) then
> >
> > is certainly up for debate.
> I have wondered why certain statements are not allowed after the test
> in the Fortran one-line if statement. Often I want to write something like
>
> if (i > 0) if (x(i) > 0.0) print*,"i, x(i)=",i,x(i)
..
Try
if (i > 0) then ; if (x(i) > 0.0) print etc ; end if