<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Blog on Fortran Modernisation Services — Fortran 2026</title>
    <link>https://fortran.sh3d.com.au/categories/blog/</link>
    <description>Recent content in Blog on Fortran Modernisation Services — Fortran 2026</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Fri, 03 Jul 2026 18:36:27 +1000</lastBuildDate>
    <atom:link href="https://fortran.sh3d.com.au/categories/blog/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>What actually breaks moving Fortran from 32-bit to 64-bit</title>
      <link>https://fortran.sh3d.com.au/blog/2026/07/03/what-actually-breaks-moving-fortran-from-32-bit-to-64-bit/</link>
      <pubDate>Fri, 03 Jul 2026 00:00:00 +0000</pubDate>
      <guid>https://fortran.sh3d.com.au/blog/2026/07/03/what-actually-breaks-moving-fortran-from-32-bit-to-64-bit/</guid>
      <description>&lt;p&gt;The optimistic version of a 64-bit migration is &amp;ldquo;change the compiler flags and&#xA;rebuild&amp;rdquo;. On a real production system — in our case an ERP that had been&#xA;running correctly for thirty years — the compile is the easy week. The&#xA;interesting failures come later, and they&amp;rsquo;re quiet.&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;The data outlives the code.&lt;/strong&gt; Binary record files written by a 32-bit&#xA;program encode integer sizes and record layouts on disk. The 64-bit build&#xA;happily reads them — into the wrong fields. Nothing crashes; the numbers are&#xA;just wrong. Every on-disk format has to be audited before the first test run&#xA;means anything.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
