The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
Subject: [TUHS] struct(1) revived!  And a request for help
Date: Wed, 12 Jan 2022 05:58:25 -0700	[thread overview]
Message-ID: <> (raw)

Hello All.

We recently discussed Brenda Baker's struct program, that read Fortran
and generated Ratfor.  Many of us remarked as to what a really cool
program it was and how much we admired it, myself included.

For fun (for some definition of "fun") I decided to try to bring the code
into the present.  I set up a GitHub repo with the V7, V8 and V10 code,
and then started work in a separate branch.

(, branch "modernize".)

The program has three main parts:

- structure, which reads Fortran and outputs something that is
  almost Ratfor on standard output.

- beautify, which reads the output of structure and finishes the job,
  primarily making conditions readable (.not. --> !, removing double
  negatives, etc.)

- - a simple shell script that runs the above two components.
  This is what the user invokes.

The code was written in 1974. As such, it is rife with "type punning"
between int, int *, int **, and char *.  These produce a lot of warnings
from a modern day C compiler.  The code also uses a, er, "unique" bracing
style, making it nearly illegible to my stuck-in-a-rut programming brain.

Here is what I've accomplished so far:

* Converted every function definition and declaration to use modern (ANSI)
  C style, adding a header file with function declarations that is
  included everywhere.

* Run all the code through the indent program, formatting it as traditional
  K&R bracing style, with tabs.

* Fixed some macros to use modern style for getting parameter values as strings
  into the macros.

* Fixed a few small bugs here and there.

* Fixed beautify to work with modern byacc/bison (%union) and to work with
  flex instead of lex. This latter was a challenge.

In structure, only three files still generate warnings, but they all relate
to integer <--> pointer assignment / use as.  However, when compiled in
32 bit mode (gcc -m32), where sizeof(int) is the same as sizeof(pointer),
despite the warnings, structure works!!

Beautify works, whether compiled in 32 or 64 bit mode.

What I've done so far has been mostly mechanical. I hereby request help from
anyone who's interested in making progress on "the hard part" --- those three
files that still generate warnings.

I think the right way to go is to replace int's with a union that holds and
int, a char* and an int*.  But I have not had the quiet time to dive into
the code to see if this can be done.

Anyone who has some time to devote to this and is interested, please drop
me a note off-list.


Arnold Robbins

             reply	other threads:[~2022-01-12 12:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-12 12:58 arnold [this message]
2022-01-13  4:23 ` [TUHS] Fwd: " Douglas McIlroy
2022-01-13  6:30   ` [TUHS] " Rich Morin
2022-01-13 15:19   ` [TUHS] Fwd: " arnold
2022-01-13 22:21 ` [TUHS] " Skip Tavakkolian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \
    --subject='Re: [TUHS] struct(1) revived'\!'  And a request for help' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).