From Newsgroup: comp.lang.c++

On 11/23/2022 5:36 PM, Tran Quoc Viet wrote:

On Saturday, November 19, 2022 at 1:01:25 PM UTC+7, Lynn McGuire wrote:

We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++
lines of code engineering software product to C++. With all that code,
we produce four Win32 EXEs and three Win32 DLLs. My goal is to add four
Win64 EXEs and three Win64 DLLs to the product with the same
capabilities as the Win32 versions (console, windowed, Excel callable,
Excel embeddable). Plus support for Unicode named files and Unicode
file paths.

I am using a customized version of f2c at the moment to automate 80% of
the conversion from F77 to C++. I have added support for logical*8,
changed the output file from *.c to *.cpp, added an include for the
Fable fem.hpp template library, removed the trailing underscores from
the subroutine and common block names, removed the ftnlen arguments from
the character arguments, converted all F77 comments to the // instead of
the /* */, and a few other items. If desired, I am willing to post a
copy of my modified f2c on my website with the source code.
https://netlib.org/f2c/
https://en.wikipedia.org/wiki/F2c

f2c does not get me totally there. The Fortran character strings were
poorly handled so they will probably needed fixing for proper sizing and
alignment. The f2c i/o code is crap so I take the original F77 i/o code
and translate it by hand. The arrays in the argument list are still
based at an index of one so I convert those to base index of zero by
hand. All of the local and common block arrays were converted to a base
index of zero by f2c. I add the new *.cpp file to my Visual Studio
project. I then add the new function prototypes to my prototypes.h file
and I add any new common block structures to my commons.h file. I then
compile and fix until I get a clean compile.

I have converted over 29,000 lines of F77 code to C++ now. Almost a
hundred subroutines and several dozen common blocks. Most are compiling
cleanly in Visual C++ 2015. My testing is working well with the
problems being in the character string area. I am still aiming for
Christmas for completing the small data analysis program in my
calculation engine. It is somewhere around 150,000 lines of F77 code.
Tough to tell since it shares so much code with my big calculation
engine which is around 600,000 lines of F77 code and 50,000 lines of
C++. They share about 75,000 lines of F77 and C++ code.

Thanks,
Lynn

Thank you for sharing your experience on that tough work. For years I
had also paid lots of effort to convert all F77 codes to modern

Fortran and I stopped that job because I found its nonsense. Is that how
we are removing Fortran from its world?

I am having problems mixing C++ and Fortran code in Visual Studio so I
am trying to move to all C++. I suspect if I was all Fortran then my
life would be easier.

Lynn

I am back on this project again. I have converted over 100,000 lines of
the F77 code to C++ now and am debugging character string issues.

I tried GFortran and GCC with Simply Fortran for a long while but the debugging is simply horrible. And I was rewriting too much of the C++
code from F77 to F2003+.

Lynn

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Lynn McGuire writes:

I am back on this project again. I have converted over 100,000 lines of the
F77 code to C++ now and am debugging character string issues.

Thanks for the update. Good job. Here's a cookie for you. Keep up the good work.

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/8/2025 1:06 PM, Lynn McGuire wrote:

On 11/23/2022 5:36 PM, Tran Quoc Viet wrote:

On Saturday, November 19, 2022 at 1:01:25 PM UTC+7, Lynn McGuire wrote:

We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++

[...]

I am back on this project again.  I have converted over 100,000 lines of the F77 code to C++ now and am debugging character string issues.

I tried GFortran and GCC with Simply Fortran for a long while but the debugging is simply horrible.  And I was rewriting too much of the C++
code from F77 to F2003+.

Good luck!


--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Tue, 8 Apr 2025 15:06:06 -0500, Lynn McGuire wrote:

I tried GFortran and GCC with Simply Fortran for a long while but the debugging is simply horrible.

Have you tried using the GNU tools (gfortran, gcc, gdb etc) directly,
leaving out the Simply Fortran middleman?
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/9/2025 2:18 AM, Lawrence D'Oliveiro wrote:

On Tue, 8 Apr 2025 15:06:06 -0500, Lynn McGuire wrote:

I tried GFortran and GCC with Simply Fortran for a long while but the
debugging is simply horrible.

Have you tried using the GNU tools (gfortran, gcc, gdb etc) directly,
leaving out the Simply Fortran middleman?

No, we want to get away from compiling and linking directly. That is
what we use with Open Watcom F77 and C++.

With over 5,000 subroutines, each in their own file, keeping track of everything is difficult on a good day.

Thanks,
Lynn
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/8/2025 7:34 PM, Sam wrote:

Lynn McGuire writes:

I am back on this project again.  I have converted over 100,000 lines
of the F77 code to C++ now and am debugging character string issues.

Thanks for the update. Good job. Here's a cookie for you. Keep up the
good work.

Sigh, the virtual cookie sucked. And I am on a diet and not supposed to
eat cookies for a long while.

Lynn

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/9/2025 1:08 AM, Chris M. Thomasson wrote:

On 4/8/2025 1:06 PM, Lynn McGuire wrote:

On 11/23/2022 5:36 PM, Tran Quoc Viet wrote:

On Saturday, November 19, 2022 at 1:01:25 PM UTC+7, Lynn McGuire

wrote:

We are converting a 700,000+ Fortran 77 lines of code plus 50,000+

C++

[...]

I am back on this project again.  I have converted over 100,000 lines
of the F77 code to C++ now and am debugging character string issues.

I tried GFortran and GCC with Simply Fortran for a long while but the
debugging is simply horrible.  And I was rewriting too much of the C++
code from F77 to F2003+.

Good luck!

Thanks, gonna need it. The conversion of Fortran character strings to
C++ strings is killing me.

Lynn

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Wed, 9 Apr 2025 14:48:12 -0500, Lynn McGuire wrote:

On 4/9/2025 2:18 AM, Lawrence D'Oliveiro wrote:

On Tue, 8 Apr 2025 15:06:06 -0500, Lynn McGuire wrote:

I tried GFortran and GCC with Simply Fortran for a long while but the
debugging is simply horrible.

Have you tried using the GNU tools (gfortran, gcc, gdb etc) directly,
leaving out the Simply Fortran middleman?

No, we want to get away from compiling and linking directly. That is
what we use with Open Watcom F77 and C++.

With over 5,000 subroutines, each in their own file, keeping track of everything is difficult on a good day.

This is why you have build systems.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Wed, 9 Apr 2025 14:48:59 -0500
Lynn McGuire <lynnmcguire5@gmail.com> wrote:

On 4/8/2025 7:34 PM, Sam wrote:

Lynn McGuire writes:

I am back on this project again.  I have converted over 100,000
lines of the F77 code to C++ now and am debugging character string
issues.

Thanks for the update. Good job. Here's a cookie for you. Keep up
the good work.

Sigh, the virtual cookie sucked. And I am on a diet and not supposed
to eat cookies for a long while.

Lynn

If I understand the poster Sam correctly, he wanted to tell you that if
you don't keep him updated about progress of your conversion project
then he wouldn't be terribly upset.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/10/2025 4:11 AM, Michael S wrote:

On Wed, 9 Apr 2025 14:48:59 -0500
Lynn McGuire <lynnmcguire5@gmail.com> wrote:

On 4/8/2025 7:34 PM, Sam wrote:

Lynn McGuire writes:

I am back on this project again.  I have converted over 100,000
lines of the F77 code to C++ now and am debugging character string
issues.

Thanks for the update. Good job. Here's a cookie for you. Keep up
the good work.

Sigh, the virtual cookie sucked. And I am on a diet and not supposed
to eat cookies for a long while.

Lynn

If I understand the poster Sam correctly, he wanted to tell you that if
you don't keep him updated about progress of your conversion project
then he wouldn't be terribly upset.

Yup, I got his sarcasm message. But I am trying to add some content to
the group.

Lynn

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/9/2025 7:35 PM, Lawrence D'Oliveiro wrote:

On Wed, 9 Apr 2025 14:48:12 -0500, Lynn McGuire wrote:

On 4/9/2025 2:18 AM, Lawrence D'Oliveiro wrote:

On Tue, 8 Apr 2025 15:06:06 -0500, Lynn McGuire wrote:

I tried GFortran and GCC with Simply Fortran for a long while but the
debugging is simply horrible.

Have you tried using the GNU tools (gfortran, gcc, gdb etc) directly,
leaving out the Simply Fortran middleman?

No, we want to get away from compiling and linking directly. That is
what we use with Open Watcom F77 and C++.

With over 5,000 subroutines, each in their own file, keeping track of
everything is difficult on a good day.

This is why you have build systems.

I started using the first IDE (interactive development environment) in
1983 ??? with Turbo Pascal. $49 IIRC. It was a simply amazing way of
doing things. Nowadays, Visual Studio comes closest to the Turbo Pascal
IDE but even it is not quite there. Visual Studios lack of a decent
Fortran compiler sucks.

I moved back to build systems on the Apollo Domain in 1989 using DSEE
but it was a downer compared to Turbo Pascal. It did allow multiple
user development teams to work together though. We only had a few
hallway fights on code conflicts, most were resolved by DSEE.

Lynn

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Thu, 10 Apr 2025 14:39:02 -0500, Lynn McGuire wrote:

On 4/9/2025 7:35 PM, Lawrence D'Oliveiro wrote:

This is why you have build systems.

I started using the first IDE (interactive development environment) in
1983 ??? with Turbo Pascal. $49 IIRC. It was a simply amazing way of
doing things. Nowadays, Visual Studio comes closest to the Turbo Pascal
IDE but even it is not quite there. Visual Studios lack of a decent
Fortran compiler sucks.

IDEs tend to be limited in their build systems. They’re not flexible: they insist you build things their way.

I moved back to build systems on the Apollo Domain in 1989 using DSEE
but it was a downer compared to Turbo Pascal. It did allow multiple
user development teams to work together though. We only had a few
hallway fights on code conflicts, most were resolved by DSEE.

Back in the day, we called them “CASE tools”, and they cost €€€. Nowadays,
they are just “developer tools”, and they are part of the standard package repositories.

The one thing Git does better than any other VCS is merging branches. No
more hallway fights ...
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/10/2025 2:52 PM, Lawrence D'Oliveiro wrote:

On Thu, 10 Apr 2025 14:39:02 -0500, Lynn McGuire wrote:

On 4/9/2025 7:35 PM, Lawrence D'Oliveiro wrote:

This is why you have build systems.

I started using the first IDE (interactive development environment) in
1983 ??? with Turbo Pascal. $49 IIRC. It was a simply amazing way of
doing things. Nowadays, Visual Studio comes closest to the Turbo Pascal
IDE but even it is not quite there. Visual Studios lack of a decent
Fortran compiler sucks.

IDEs tend to be limited in their build systems. They’re not flexible: they insist you build things their way.

I moved back to build systems on the Apollo Domain in 1989 using DSEE
but it was a downer compared to Turbo Pascal. It did allow multiple
user development teams to work together though. We only had a few
hallway fights on code conflicts, most were resolved by DSEE.

Back in the day, we called them “CASE tools”, and they cost €€€. Nowadays,
they are just “developer tools”, and they are part of the standard package
repositories.

The one thing Git does better than any other VCS is merging branches. No
more hallway fights ...

One of my items on my long term plan is to move from CVSNT to Git. I am
so tired of CVSNT's blowing up a code merge, usually comments. I have
about 22,000 files being versioned at the moment. We have been using
CVSNT since 1993 or so. Some files have over 600+ versions so the move
will not be trivial.

There are only three of us software developers here so we do not have
many code merge problems.

Lynn


--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Am 09.04.2025 um 21:48 schrieb Lynn McGuire:

No, we want to get away from compiling and linking directly.
That is what we use with Open Watcom F77 and C++.

The Watcom stuff is totally outdated.
Is there no way to get something newer ?
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Fri, 11 Apr 2025 11:37:17 +0200, Bonita Montero wrote:

Am 09.04.2025 um 21:48 schrieb Lynn McGuire:

No, we want to get away from compiling and linking directly.
That is what we use with Open Watcom F77 and C++.

The Watcom stuff is totally outdated.
Is there no way to get something newer ?

You must be new here in c.l.f. Lynn has been converting
his 700 KLOC of Fortran to C++ for 2+ decades. It seems
his code, which clearly isn't Fortran, can only be compiled
by a Watcom language compiler. For those playing along,
that's roughy converting 140 lines of code per workday
with 2 weeks for good behavior (ie., 700000 / (50*5*20)).
--
steve
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/11/25 12:00, Steven G. Kargl wrote:
...

You must be new here in c.l.f. Lynn has been converting
his 700 KLOC of Fortran to C++ for 2+ decades. It seems
his code, which clearly isn't Fortran, can only be compiled

This is cross-posted to comp.lang.c++, which is where I'm seeing it.
It's not very important, but I'm curious as to what about his code makes
it clearly not Fortran code. Has he conceded that it isn't actually
fortran? The Subject of this thread implies otherwise.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Fri, 11 Apr 2025 12:25:53 -0400, James Kuyper wrote:

On 4/11/25 12:00, Steven G. Kargl wrote:
...

You must be new here in c.l.f. Lynn has been converting
his 700 KLOC of Fortran to C++ for 2+ decades. It seems
his code, which clearly isn't Fortran, can only be compiled

This is cross-posted to comp.lang.c++, which is where I'm seeing it.
It's not very important, but I'm curious as to what about his code makes
it clearly not Fortran code. Has he conceded that it isn't actually
fortran? The Subject of this thread implies otherwise.

Vendor extensions.

We have here a classic example of code, purportedly written
in a language with an international standard, doomed by
vendor lock-in.
--
steve
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/11/2025 11:00 AM, Steven G. Kargl wrote:

On Fri, 11 Apr 2025 11:37:17 +0200, Bonita Montero wrote:

Am 09.04.2025 um 21:48 schrieb Lynn McGuire:

No, we want to get away from compiling and linking directly.
That is what we use with Open Watcom F77 and C++.

The Watcom stuff is totally outdated.
Is there no way to get something newer ?

You must be new here in c.l.f. Lynn has been converting
his 700 KLOC of Fortran to C++ for 2+ decades. It seems
his code, which clearly isn't Fortran, can only be compiled
by a Watcom language compiler. For those playing along,
that's roughy converting 140 lines of code per workday
with 2 weeks for good behavior (ie., 700000 / (50*5*20)).

My Fortran code worked just fine using the Unix f77 compiler while I was supporting our Sun, HP UX, and Apollo Domain users. I think that I used
the CC compiler back then for our C code before we started adding C++
code in the 2000s after our users all moved to Windows. Been a long
time though, early to late 1990s.

Lynn

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/11/2025 11:00 AM, Steven G. Kargl wrote:

On Fri, 11 Apr 2025 11:37:17 +0200, Bonita Montero wrote:

Am 09.04.2025 um 21:48 schrieb Lynn McGuire:

No, we want to get away from compiling and linking directly.
That is what we use with Open Watcom F77 and C++.

The Watcom stuff is totally outdated.
Is there no way to get something newer ?

You must be new here in c.l.f. Lynn has been converting
his 700 KLOC of Fortran to C++ for 2+ decades. It seems
his code, which clearly isn't Fortran, can only be compiled
by a Watcom language compiler. For those playing along,
that's roughy converting 140 lines of code per workday
with 2 weeks for good behavior (ie., 700000 / (50*5*20)).

Don't forget maintenance (bug fixing) and user needed new features that require about 60 to 70% of our time.

Lynn

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/11/2025 3:47 PM, Lynn McGuire wrote:

On 4/11/2025 11:00 AM, Steven G. Kargl wrote:

On Fri, 11 Apr 2025 11:37:17 +0200, Bonita Montero wrote:

Am 09.04.2025 um 21:48 schrieb Lynn McGuire:

No, we want to get away from compiling and linking directly.
That is what we use with Open Watcom F77 and C++.

The Watcom stuff is totally outdated.
Is there no way to get something newer ?

You must be new here in c.l.f.  Lynn has been converting
his 700 KLOC of Fortran to C++ for 2+ decades.  It seems
his code, which clearly isn't Fortran, can only be compiled
by a Watcom language compiler.  For those playing along,
that's roughy converting 140 lines of code per workday
with 2 weeks for good behavior (ie., 700000 / (50*5*20)).

Don't forget maintenance (bug fixing) and user needed new features that require about 60 to 70% of our time.

Lynn

And don't forget that we spent a lot of time updating the code by
converting all of the Hollerith characters to character strings. And
adding "IMPLICIT NONE" to all of the subroutines requiring the explicit
typing of all of the variables (maybe 10% were typed before due to
extensive usage of implicit typing rules).

Lynn

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Sun, 13 Apr 2025 17:59:26 -0500, Lynn McGuire wrote:

And don't forget that we spent a lot of time updating the code by
converting all of the Hollerith characters to character strings.

34HSee, that I would have left alone.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/13/2025 6:10 PM, Lawrence D'Oliveiro wrote:

On Sun, 13 Apr 2025 17:59:26 -0500, Lynn McGuire wrote:

And don't forget that we spent a lot of time updating the code by
converting all of the Hollerith characters to character strings.

34HSee, that I would have left alone.

Got rid of a few nasty bugs like:

iword = 6Habcdef

Lynn

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Mon, 14 Apr 2025 23:50:32 -0500, Lynn McGuire wrote:

Got rid of a few nasty bugs like:

iword = 6Habcdef

Surely whether that’s a bug or not would depend on the type of “iword” ...
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/15/2025 6:14 PM, Lawrence D'Oliveiro wrote:

On Mon, 14 Apr 2025 23:50:32 -0500, Lynn McGuire wrote:

Got rid of a few nasty bugs like:

iword = 6Habcdef

Surely whether that’s a bug or not would depend on the type of “iword” ...

iword is a implicit 4 byte integer capable of storing 4 characters.

Lynn

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/15/2025 5:28 PM, Lynn McGuire wrote:

On 4/15/2025 6:14 PM, Lawrence D'Oliveiro wrote:

On Mon, 14 Apr 2025 23:50:32 -0500, Lynn McGuire wrote:

Got rid of a few nasty bugs like:

        iword = 6Habcdef

Surely whether that’s a bug or not would depend on the type of
“iword” ...

iword is a implicit 4 byte integer capable of storing 4 characters.

Out of curiosity, what system was this originally written for?

Louis

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Tue, 15 Apr 2025 18:28:31 -0500, Lynn McGuire wrote:

On 4/15/2025 6:14 PM, Lawrence D'Oliveiro wrote:

On Mon, 14 Apr 2025 23:50:32 -0500, Lynn McGuire wrote:

Got rid of a few nasty bugs like:

iword = 6Habcdef

Surely whether that’s a bug or not would depend on the type of “iword” >> ...

iword is a implicit 4 byte integer capable of storing 4 characters.

I thought you got rid of all the implicit typing.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Wed, 16 Apr 2025 07:44:08 +0000, Lawrence D'Oliveiro wrote:

On Tue, 15 Apr 2025 18:28:31 -0500, Lynn McGuire wrote:

On 4/15/2025 6:14 PM, Lawrence D'Oliveiro wrote:

On Mon, 14 Apr 2025 23:50:32 -0500, Lynn McGuire wrote:

Got rid of a few nasty bugs like:

iword = 6Habcdef

Surely whether that’s a bug or not would depend on the type of “iword”
...

iword is a implicit 4 byte integer capable of storing 4 characters.

I thought you got rid of all the implicit typing.

Implicit typing has nothing do with numeric storage size.

program foo
use iso_fortran_env, only : numeric_storage_size
integer :: j = 0
i = 6Habcdef ! i has an implicit type of default integer kind
j = 6Habcdef ! j has an explicit type of default integer kind
print *, i, j
print *, numeric_storage_size
end program foo

% gfcx -std=legacy -o z a.f90
% ./z
1684234849 1684234849
32

Many (most? all?) systems today likely have a 4-byte internal
representation for a default integer. The Fortran standard simply
states that 'i' and 'j' occupy one numeric storage unit. Here,
the size of that unit is 32 bits.

PS: The gfortran's -Wall option reports a few warnings with
the above code.

% gfcx -std=legacy -o z -Wall a.f90
a.f90:26:7:

26 | i = 6Habcdef
| 1
Warning: Conversion from HOLLERITH to INTEGER(4) at (1)
[-Wconversion]
a.f90:26:7:

26 | i = 6Habcdef
| 1
Warning: The Hollerith constant at (1) is truncated in
conversion to 'INTEGER(4' [-Wcharacter-truncation]

and similar warnings for 'j'.
--
steve
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/16/2025 12:19 AM, Louis Krupp wrote:

On 4/15/2025 5:28 PM, Lynn McGuire wrote:

On 4/15/2025 6:14 PM, Lawrence D'Oliveiro wrote:

On Mon, 14 Apr 2025 23:50:32 -0500, Lynn McGuire wrote:

Got rid of a few nasty bugs like:

        iword = 6Habcdef

Surely whether that’s a bug or not would depend on the type of
“iword” ...

iword is a implicit 4 byte integer capable of storing 4 characters.

Out of curiosity, what system was this originally written for?

Louis

Univac 1108. 6 bit bytes (no lowercase) and 6 bytes per word made 36
bit words. Our first port to the IBM 370 in 1975 ??? was hell since it
was a four byte mainframe.

The CDC 7600 was awesome, 6 bit bytes and 10 bytes per word made 60 bit
words. Single precision was almost as good as double precision on any
other mainframe.

Lynn

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 4/16/2025 2:44 AM, Lawrence D'Oliveiro wrote:

On Tue, 15 Apr 2025 18:28:31 -0500, Lynn McGuire wrote:

On 4/15/2025 6:14 PM, Lawrence D'Oliveiro wrote:

On Mon, 14 Apr 2025 23:50:32 -0500, Lynn McGuire wrote:

Got rid of a few nasty bugs like:

iword = 6Habcdef

Surely whether that’s a bug or not would depend on the type of “iword”
...

iword is a implicit 4 byte integer capable of storing 4 characters.

I thought you got rid of all the implicit typing.

Yup, we did get rid of the implicit typing. That is what showed up when
did.

Lynn

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Steven G. Kargl wrote:

On Wed, 16 Apr 2025 07:44:08 +0000, Lawrence D'Oliveiro wrote:

On Tue, 15 Apr 2025 18:28:31 -0500, Lynn McGuire wrote:

On 4/15/2025 6:14 PM, Lawrence D'Oliveiro wrote:

On Mon, 14 Apr 2025 23:50:32 -0500, Lynn McGuire wrote:

Got rid of a few nasty bugs like:

iword = 6Habcdef

Surely whether that’s a bug or not would depend on the type of “iword”
...

iword is a implicit 4 byte integer capable of storing 4 characters.

I thought you got rid of all the implicit typing.

Implicit typing has nothing do with numeric storage size.

program foo
use iso_fortran_env, only : numeric_storage_size
integer :: j = 0
i = 6Habcdef ! i has an implicit type of default integer kind
j = 6Habcdef ! j has an explicit type of default integer kind
print *, i, j
print *, numeric_storage_size
end program foo

% gfcx -std=legacy -o z a.f90
% ./z
1684234849 1684234849
32

Many (most? all?) systems today likely have a 4-byte internal
representation for a default integer. The Fortran standard simply
states that 'i' and 'j' occupy one numeric storage unit. Here,
the size of that unit is 32 bits.

PS: The gfortran's -Wall option reports a few warnings with
the above code.

% gfcx -std=legacy -o z -Wall a.f90
a.f90:26:7:

26 | i = 6Habcdef
| 1
Warning: Conversion from HOLLERITH to INTEGER(4) at (1)
[-Wconversion]
a.f90:26:7:

26 | i = 6Habcdef
| 1
Warning: The Hollerith constant at (1) is truncated in
conversion to 'INTEGER(4' [-Wcharacter-truncation]

and similar warnings for 'j'.

I believe you'll find that some of that syntax did not exist under
Fortran 77, in particular the "use" line.
Did Lynn convert to F90 first?
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Thu, 17 Apr 2025 12:24:22 +0200, R Daneel Olivaw wrote:

Steven G. Kargl wrote:

On Wed, 16 Apr 2025 07:44:08 +0000, Lawrence D'Oliveiro wrote:

On Tue, 15 Apr 2025 18:28:31 -0500, Lynn McGuire wrote:

On 4/15/2025 6:14 PM, Lawrence D'Oliveiro wrote:

On Mon, 14 Apr 2025 23:50:32 -0500, Lynn McGuire wrote:

Got rid of a few nasty bugs like:

iword = 6Habcdef

Surely whether that’s a bug or not would depend on the type of “iword”
...

iword is a implicit 4 byte integer capable of storing 4 characters.

I thought you got rid of all the implicit typing.

Implicit typing has nothing do with numeric storage size.

program foo
use iso_fortran_env, only : numeric_storage_size
integer :: j = 0
i = 6Habcdef ! i has an implicit type of default integer kind
j = 6Habcdef ! j has an explicit type of default integer kind
print *, i, j
print *, numeric_storage_size
end program foo

(snip)

I believe you'll find that some of that syntax did not exist under
Fortran 77, in particular the "use" line.
Did Lynn convert to F90 first?

Of course, the USE statement was not part of FORTRAN 77.
(It was added in Fortran 90). The intrinsic module
iso_fortran_env was not part of FORTRAN 77. (It was
added in Fortran 2003). I included that line to easily
get to the number of bits in a numeric storage unit.
From ANSI X3.9-1978 (i.e., FORTRAN 77):

An integer, real, or logical datum has one numeric
storage unit in a storage sequence.
...
This standard does not specify a relationship between
the storage sequence concept and the physical properties
or implementation of storage.

The size of the unit was not specified in FORTRAN 77, and
this concept is still alive in Fortran 2023.
--
steve
--- Synchronet 3.20c-Linux NewsLink 1.2