From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21318 invoked from network); 13 Jan 2022 04:24:16 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 13 Jan 2022 04:24:16 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 9662F9D02C; Thu, 13 Jan 2022 14:24:13 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 18B089CF7E; Thu, 13 Jan 2022 14:23:47 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=dartmouth.edu header.i=@dartmouth.edu header.b="WXhavXnT"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id D71EA9CF7E; Thu, 13 Jan 2022 14:23:44 +1000 (AEST) Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by minnie.tuhs.org (Postfix) with ESMTPS id B17989C78F for ; Thu, 13 Jan 2022 14:23:41 +1000 (AEST) Received: by mail-wm1-f51.google.com with SMTP id l4so2971433wmq.3 for ; Wed, 12 Jan 2022 20:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dartmouth.edu; s=google1; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gn7C8K/mq+1QxLfhR8mHDI338RQZK6yza+3Zr9P+6G8=; b=WXhavXnTgE3v4g/EJvKAMLkYDay77a0/C5CDGlxKmm+OHPfc9WbHDeTzepmS60BXoQ 2D2Msr1N1H2yvZBu2qTreCDfL1S+TMeAOVhz7jp4RtGhBixpGBvoOwItVOLpzOH0gxBL 5nScRawtknuxLg4hFRms2c+2vKQZjBZADrDMKp5hQAW6IIqyNgJaief8tlNdGPcjF4Ut a0FAXLUaTTChcxrACme0W1bzyboiEZPOEm1nw1wuZrA+ord6PBk+pcXMuVRqbaoMjUkx xTeauxLPSbqQGFbVD4MJSFRCNQwzXgcU+Tnm/zHoGXnmctTxPbGBzmoA+VsvVT26+k/K ndeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gn7C8K/mq+1QxLfhR8mHDI338RQZK6yza+3Zr9P+6G8=; b=ikX63vGRqla9R3mtxpm97ESzs5Bro4XULRj1k7fkOrXJIE9OXYPPYLQwZ60x5YOrSD YZMSW7SWR02ZTPv1WyxuwjKf5U5hCiT3Jr8o4qCrW3iscsih7B5Sc/72cPy29Lupaxs8 X5imABd4UpNgHyvWRcDdXJntRwh2dcY4Bt+CAY0Aut/Qtlbyuj8qLDUsnMjr8f6CHMw4 KrtuyL7TJWaHfkidIGuFZa2U4kmaU6UNyJ5jGjzj58ChctR8WaHa4dfMcySA9zw1lAcz oZGQ1+x3hPy2NFHicm0Cb7rspwp3uQM0jpdBuPoxCd6x1Q8hqJLT2BZYgqvy1sunUj4A WNZg== X-Gm-Message-State: AOAM5321tNeVUB6rf4bmWnq4kAIQVVbhBL7334CYKhbOhLWYQgEsPtH4 HovGdtAoBVuszV4tF4gV3wQ2mbwx/7LC6Vdr5tRF+7IPR7A= X-Google-Smtp-Source: ABdhPJwSxOSXap70VQdsEFCugMzcFp/ugDH+lFJaSiJK5XYkHJTWl8a87OXMse2u+rsCGitgvuWgipwbvUt6WakesTs= X-Received: by 2002:a05:600c:3b18:: with SMTP id m24mr2111913wms.4.1642047820147; Wed, 12 Jan 2022 20:23:40 -0800 (PST) MIME-Version: 1.0 References: <202201121258.20CCwPEF013323@freefriends.org> In-Reply-To: <202201121258.20CCwPEF013323@freefriends.org> From: Douglas McIlroy Date: Wed, 12 Jan 2022 23:23:23 -0500 Message-ID: To: TUHS main list Content-Type: text/plain; charset="UTF-8" Subject: [TUHS] Fwd: struct(1) revived! And a request for help X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Brenda Baker Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Arnold, I'm very glad you have revived struct. It is an important historical artifact, and it's nice to have it freed from distracting obsolete usage. To my mind, struct ranks among the top accomplishments of our department at Bell Labs. It was also a lesson in humility to me. When Brenda proposed struct, it was obvious that it could be built, but I advised against doing so. I thought it would take an endless pile of special cases to generate respectable Ratfor. She demurred, saying that she thought she could do better than that. And she was right. She produced not only working Ratfor programs, but a canonical-form theorem that distinguished those programs from all the ad hoc alternatives I had imagined. The value of the theorem was attested by users' reports that the derived Ratfort was easier to understand than the Fortran they had written themselves. Doug ---------- Forwarded message --------- From: Date: Wed, Jan 12, 2022 at 7:58 AM Subject: [TUHS] struct(1) revived! And a request for help To: 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. (https://github.com/arnoldrobbins/struct, 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.) - struct.sh - 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. Thanks, Arnold Robbins