This is related to the space / word boundary issue (based on how the language worked) that does not have a good solution. As I think I might have written in the remarks I tried different ways but each way caused other problems, problems that would make Navajo -> English not work even when it should otherwise. Although the index.html already showed some examples of this it seems good to include some in the bugs.html and add the INABIAF tag to the index.html.
1989 lines
116 KiB
HTML
1989 lines
116 KiB
HTML
<!DOCTYPE html>
|
||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||
<!-- START: two lines up starts content from: inc/top.default.html -->
|
||
|
||
<!-- END: this line ends content from: inc/top.default.html -->
|
||
<!-- START: this line starts content from: inc/head.default.html -->
|
||
|
||
<head>
|
||
<link rel="stylesheet" href="../../ioccc.css">
|
||
<link href="https://fonts.googleapis.com/css2?family=Outfit:wght@100..900&display=swap" rel="stylesheet">
|
||
<meta charset="utf-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
|
||
<title>2024/ferguson2 - Prize in yil-tas</title>
|
||
<link rel="icon" type="image/x-icon" href="../../favicon.ico">
|
||
<meta name="description" content="2024 IOCCC entry ferguson2 - Prize in yil-tas">
|
||
<meta name="keywords" content="IOCCC, 2024, IOCCC 2024, IOCCC entry, ferguson2, Prize in yil-tas">
|
||
</head>
|
||
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||
<!-- !!! DO NOT MODIFY THIS FILE - This file is generated by a tool !!! -->
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
|
||
<!-- END: this line ends content from: inc/head.default.html -->
|
||
|
||
<!-- -->
|
||
<!-- This web page was formed via the tool: bin/readme2index.sh -->
|
||
<!-- The content of main section of this web page came from: 2024/ferguson2/README.md -->
|
||
<!-- -->
|
||
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: 2024/ferguson2/README.md !!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: 2024/ferguson2/README.md !!! -->
|
||
<!-- !!! Do not modify this web page, instead modify the file: 2024/ferguson2/README.md !!! -->
|
||
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
|
||
|
||
<!-- Markdown content was converted into HTML via the tool: bin/md2html.sh -->
|
||
|
||
<!-- START: this line starts content from: inc/body.default.html -->
|
||
|
||
<body>
|
||
|
||
<!-- END: this line ends content from: inc/body.default.html -->
|
||
<!-- START: this line starts content from: inc/topbar.default.html -->
|
||
|
||
<div class="theader">
|
||
<nav class="topbar">
|
||
<div class="container">
|
||
<div class="logo">
|
||
<a href="../../index.html" class="logo-link">
|
||
IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="topbar-items">
|
||
<div class="item">
|
||
<span class="item-header">
|
||
Entries
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../years.html" class="sub-item-link">
|
||
Winning entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../authors.html" class="sub-item-link">
|
||
Winning authors
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../location.html" class="sub-item-link">
|
||
Location of authors
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../bugs.html" class="sub-item-link">
|
||
Bugs and (mis)features
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../faq.html#fix_an_entry" class="sub-item-link">
|
||
Fixing entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../faq.html#fix_author" class="sub-item-link">
|
||
Updating author info
|
||
</a>
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="item">
|
||
<span class="item-header">
|
||
Status
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../news.html" class="sub-item-link">
|
||
News
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../status.html" class="sub-item-link">
|
||
Contest status
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../next/rules.html" class="sub-item-link">
|
||
IOCCC rules
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../next/guidelines.html" class="sub-item-link">
|
||
IOCCC guidelines
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../markdown.html" class="sub-item-link">
|
||
Markdown guidelines
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../SECURITY.html" class="sub-item-link">
|
||
Security policy
|
||
</a>
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="item">
|
||
<span class="item-header">
|
||
FAQ
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../faq.html" class="sub-item-link">
|
||
Frequently asked questions
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../quick-start.html#enter" class="sub-item-link">
|
||
Enter the IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../faq.html#compiling" class="sub-item-link">
|
||
Compiling entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../faq.html#running_entries" class="sub-item-link">
|
||
Running entries
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../faq.html#help" class="sub-item-link">
|
||
How to help
|
||
</a>
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="item">
|
||
<span class="item-header">
|
||
About
|
||
</span>
|
||
|
||
<div class="sub-item">
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../index.html" class="sub-item-link">
|
||
Home page
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../social.html" class="sub-item-link">
|
||
IOCCC social media
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../about.html" class="sub-item-link">
|
||
About the IOCCC
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../judges.html" class="sub-item-link">
|
||
The judges
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../thanks-for-help.html" class="sub-item-link">
|
||
Thanks for the help
|
||
</a>
|
||
</div>
|
||
|
||
<div class="outfit-font">
|
||
<a href="../../contact.html" class="sub-item-link">
|
||
Contact us
|
||
</a>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</nav>
|
||
|
||
<div class="header-mobile-menu">
|
||
<noscript>
|
||
<a href="../../nojs-menu.html" class="topbar-js-label">
|
||
Please Enable JavaScript
|
||
</a>
|
||
</noscript>
|
||
|
||
<button id="header-open-menu-button" class="topbar-mobile-menu">
|
||
<img
|
||
src="../../png/hamburger-icon-open.png"
|
||
alt="hamburger style menu icon - open state"
|
||
width=48
|
||
height=48>
|
||
</button>
|
||
|
||
<button id="header-close-menu-button" class="hide-content">
|
||
<img
|
||
src="../../png/hamburger-icon-closed.png"
|
||
alt="hamburger style menu icon - closed state"
|
||
width=48
|
||
height=48>
|
||
</button>
|
||
|
||
<div id="mobile-menu-panel" class="hide-content">
|
||
<div class="mobile-menu-container">
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
<div class="mobile-menu-item">
|
||
Entries
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../../years.html">
|
||
Winning entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../authors.html">
|
||
Winning authors
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../location.html">
|
||
Location of authors
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../bugs.html">
|
||
Bugs and (mis)features
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../faq.html#fix_an_entry">
|
||
Fixing entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../faq.html#fix_author">
|
||
Updating author info
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../thanks-for-help.html">
|
||
Thanks for the help
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
|
||
<div class="mobile-menu-item">
|
||
Status
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../../news.html">
|
||
News
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../status.html">
|
||
Contest status
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../next/rules.html">
|
||
IOCCC rules
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../next/guidelines.html">
|
||
IOCCC guidelines
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../markdown.html">
|
||
Markdown guidelines
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../SECURITY.html">
|
||
Security policy
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
<div class="mobile-menu-item">
|
||
FAQ
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../../faq.html">
|
||
Frequently asked questions
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../quick-start.html#enter">
|
||
Enter the IOCCC
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../faq.html#compiling">
|
||
Compiling entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../faq.html#running_entries">
|
||
Running entries
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../faq.html#help">
|
||
How to help
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="mobile-menu-wrapper">
|
||
<div class="mobile-menu-item">
|
||
About
|
||
</div>
|
||
<div class="mobile-submenu-wrapper">
|
||
|
||
<a class="mobile-submenu-item" href="../../index.html">
|
||
Home page
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../social.html">
|
||
IOCCC social media
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../about.html">
|
||
About the IOCCC
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../judges.html">
|
||
The judges
|
||
</a>
|
||
|
||
<a class="mobile-submenu-item" href="../../contact.html">
|
||
Contact us
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
</div>
|
||
|
||
<script>
|
||
var headerOpenMenuButton = document.getElementById("header-open-menu-button");
|
||
var headerCloseMenuButton = document.getElementById("header-close-menu-button");
|
||
var mobileMenuPanel = document.getElementById("mobile-menu-panel");
|
||
|
||
headerOpenMenuButton.addEventListener("click", () => {
|
||
headerOpenMenuButton.classList.remove("topbar-mobile-menu");
|
||
headerOpenMenuButton.classList.add("hide-content");
|
||
|
||
headerCloseMenuButton.classList.remove("hide-content");
|
||
headerCloseMenuButton.classList.add("topbar-mobile-menu");
|
||
|
||
mobileMenuPanel.classList.remove("hide-content");
|
||
mobileMenuPanel.classList.add("topbar-mobile-panel");
|
||
});
|
||
|
||
headerCloseMenuButton.addEventListener("click", () => {
|
||
headerCloseMenuButton.classList.remove("topbar-mobile-menu");
|
||
headerCloseMenuButton.classList.add("hide-content");
|
||
|
||
mobileMenuPanel.classList.add("hide-content");
|
||
mobileMenuPanel.classList.remove("topbar-mobile-panel");
|
||
|
||
headerOpenMenuButton.classList.add("topbar-mobile-menu");
|
||
headerOpenMenuButton.classList.remove("hide-content");
|
||
});
|
||
</script>
|
||
|
||
<!-- END: this line ends content from: inc/topbar.default.html -->
|
||
<!-- START: this line starts content from: inc/header.default.html -->
|
||
|
||
<div class="header">
|
||
<a href="../../2011/zucker/index.html">
|
||
<img src="../../png/ioccc.png"
|
||
alt="IOCCC image by Matt Zucker"
|
||
width=300
|
||
height=110>
|
||
</a>
|
||
<h1>The International Obfuscated C Code Contest</h1>
|
||
<h2>2024/ferguson2 - Prize in yil-tas</h2>
|
||
<h3>Navajo Code Talker translator</h3>
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/header.default.html -->
|
||
<!-- START: this line starts content from: inc/navbar.mid.html -->
|
||
|
||
<div class="navbar">
|
||
<a class="Left" href="../ferguson1/index.html">← 2024/ferguson1</a>
|
||
<a class="Left" href="../index.html">↑ 2024 ↑</a>
|
||
<a class="Left" href="../howe/index.html">2024/howe →</a>
|
||
<a class="Right" href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/prog.c">C code</a>
|
||
<a class="Right" href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/Makefile">Makefile</a>
|
||
<a class="Right" href="#inventory">Inventory</a>
|
||
<a class="Right" href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/prog.orig.c">Original C</a>
|
||
<a class="Right" href="https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.ioccc.org%2F2024%2Fferguson2%2Findex.html">✓</a>
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/navbar.mid.html -->
|
||
<!-- START: this line starts content from: inc/before-content.default.html -->
|
||
|
||
<div class="content" id="content">
|
||
|
||
<!-- END: this line ends content from: inc/before-content.default.html -->
|
||
<!-- START: this line starts content for HTML phase 20 by: bin/output-index-author.sh via bin/md2html.sh -->
|
||
|
||
<!-- START: this line starts content generated by: bin/output-index-author.sh -->
|
||
|
||
<h2 id="author">Author:</h2>
|
||
<ul>
|
||
<li>Name: <a href="../../authors.html#Cody_Boone_Ferguson">Cody Boone Ferguson</a><br>
|
||
Location: <a href="../../location.html#US">US</a> - <em>United States of America</em> (<em>United States</em>)</li>
|
||
</ul>
|
||
|
||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||
|
||
<!-- END: this line ends content for HTML phase 20 by: bin/output-index-author.sh via bin/md2html.sh -->
|
||
<!-- START: this line starts content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||
|
||
<!-- BEFORE: 1st line of markdown file: 2024/ferguson2/README.md -->
|
||
<h2 id="award-presentation">Award presentation:</h2>
|
||
<p>Watch the <a href="https://www.youtube.com/@OurFavoriteUniverse">Our Favorite Universe</a>
|
||
YouTube show for this entry:</p>
|
||
<blockquote>
|
||
<p><a href="https://www.youtube.com/watch?v=KmSzapLxDnA">IOCCC28 - 2024/ferguson2 - Prize in yil-tas</a></p>
|
||
</blockquote>
|
||
<h2 id="to-build">To build:</h2>
|
||
<pre><code> make all</code></pre>
|
||
<h3 id="bugs-and-misfeatures">Bugs and (Mis)features:</h3>
|
||
<p>The current status of this entry is:</p>
|
||
<blockquote>
|
||
<p><strong>STATUS: INABIAF - please DO NOT fix</strong></p>
|
||
</blockquote>
|
||
<p>For more detailed information see <a href="../../bugs.html#2024_ferguson2">2024/ferguson2 in bugs.html</a>.</p>
|
||
<h2 id="to-use">To use:</h2>
|
||
<pre><code> ./prog 'some string'
|
||
./prog +file</code></pre>
|
||
<h2 id="try">Try:</h2>
|
||
<pre><code> ./try.sh</code></pre>
|
||
<h2 id="alternate-code">Alternate code:</h2>
|
||
<p>The author provided alternate code which takes the output of <code>prog</code> and decodes
|
||
it back to the original input.</p>
|
||
<h3 id="alternate-build">Alternate build:</h3>
|
||
<pre><code> make alt</code></pre>
|
||
<h3 id="alternate-use">Alternate use:</h3>
|
||
<pre><code> ./prog.alt 'some other string'
|
||
./prog.alt +filename</code></pre>
|
||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||
<p>The IOCCC is honored to present this entry with an award that, in turn,
|
||
recognizes the <a href="https://en.wikipedia.org/wiki/Code_talker#Navajo">Navajo Code Talkers</a>
|
||
who served with distinction during World War II.</p>
|
||
<p>As noted in a <a href="https://www.nytimes.com/2014/06/06/us/chester-nez-dies-at-93-his-native-tongue-helped-to-win-a-war-of-words.html">NY Times article on Chester Nez</a>:</p>
|
||
<blockquote>
|
||
<p>Not fully declassified until 1968, the Navajo code remains the only oral military
|
||
code that (was) never been broken (in the field of operations).</p>
|
||
</blockquote>
|
||
<p>This submission encodes (pun intended) the basic algorithm used by Navajo Code Talkers
|
||
to encode and decode messages. We invite you to attempt to decipher the C code,
|
||
and then to explore the fascinating cryptographic history of <a href="https://en.wikipedia.org/wiki/Code_talker">Code Talking</a>.</p>
|
||
<h3 id="on-a-personal-ioccc-judge-note">On a personal IOCCC Judge note</h3>
|
||
<p>One of the IOCCC Judges had the unique opportunity to engage in
|
||
discussions with Code Talkers, sharing insights into the intricacies of
|
||
the code as well as the practical variations that were developed in the
|
||
field between pairs of Code Talkers.</p>
|
||
<p>The discussion provided some fascinating insights into the amazing
|
||
<a href="https://en.wikipedia.org/wiki/Navajo_language">Navajo language</a>
|
||
including its unique grammar, and examples of some of the intricate
|
||
nuances available to a native fluent speaker. Due to the complex
|
||
syntax, phonology, and numerous dialects available in the Navajo
|
||
language, the IOCCC Judge was only able to grasp a superficial
|
||
understanding of the topic. Nevertheless, it was evident to the
|
||
IOCCC Judge, why the Navajo language developed an ideal Code Talker
|
||
framework during World War II, and it is worth noting that
|
||
<a href="https://archive.library.nau.edu/digital/collection/cpa/id/44718">fewer than 30 non-Navajo individuals</a>
|
||
could comprehend the language during World War II.</p>
|
||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||
<h3 id="navajo-code-talker-language-of-the-second-world-war">Navajo Code Talker language of the Second World War</h3>
|
||
<p>This entry (<code>ctt</code>) is a translator of the Navajo Code Talker language used in
|
||
the Second World War.</p>
|
||
<p>However since the language is too long for the <code>iocccsize</code> restrictions I have
|
||
had to read in the dictionary from a file (default <code>dict</code> defined in the
|
||
Makefile so one can override this - if they figure out the format anyway, as
|
||
that is also somewhat encrypted, albeit not much, though I explain the details
|
||
later on).</p>
|
||
<p>At the same time I have made it more fun because I have made it so that one can
|
||
translate back and forth words that were not in the dictionary. This is done
|
||
because we have the alphabet as well so we can simply spell out words; the Code
|
||
Talkers also did this so this is completely in line with a translator. That’s
|
||
done with the alt code with a different definition of the macro <code>X</code>, although as
|
||
you’ll see there are some differences in the code (not just format but
|
||
output too).</p>
|
||
<p>A note about the iocccsize and the dictionary. If you take a look you’ll see
|
||
that the alphabet is in the source code (well some of it: the letters that have
|
||
more than one translation only have one again for the reason noted). Actually
|
||
the dictionary has the letters too but this is about all I could fit in and it
|
||
offers for some fun obfuscation as well even though the alphabet is not
|
||
enciphered (there was more than one word for each letter, or at least some if
|
||
not all, however, and only one is included in the code).</p>
|
||
<p>The program does not include literal translations although it is possible to
|
||
modify the code to do this. Instead it is the English to Navajo word that was
|
||
used in the military; the literal translation was what it meant in their
|
||
language.</p>
|
||
<p>With the <code>DICT</code> macro the dictionary is not hardcoded although the dictionary is
|
||
not English in look. I discuss how it’s done <a href="#how">here</a>.</p>
|
||
<h3 id="who-were-the-code-talkers">Who were the Code Talkers ?</h3>
|
||
<p>One of the original Code Talkers had this fascinating thing to say:</p>
|
||
<blockquote>
|
||
<p>We acted as coding machines, transmitting messages that would have taken a
|
||
couple of hours in just a couple of minutes. We could never make a mistake,
|
||
because many communications involved bombing coordinates.</p>
|
||
<p>– Navajo Code Talker Chester Nez in a 2012 interview with the website ArmchairGeneral.com.</p>
|
||
</blockquote>
|
||
<p>This is one of the reasons I think this language should be in an IOCCC entry:
|
||
they were coding machines, transmitting messages that would normally take hours
|
||
but they did it in their head in just a couple of minutes!</p>
|
||
<p>Chester Nez also wrote a fascinating book (which I highly recommend if the
|
||
Second World War is your interest): <a href="https://www.amazon.co.uk/Code-Talker-Memoir-Original-Talkers/dp/0425247856/ref=sr_1_1?crid=2CZLDH32F4AFG&keywords=code+talker+the+first+and+only&qid=1689845060&sprefix=code+talker+the+first+and+onl%2Caps%2C457&sr=8-1">Code Talker: The First and Only Memoir By
|
||
One of the Original Navajo Code Talkers of
|
||
WWII</a>
|
||
(if you’re in the US you might prefer the <a href="https://www.amazon.com/Code-Talker-Memoir-Original-Talkers/dp/0425247856/ref=sr_1_1?crid=3BJX333D0QZIW&keywords=code+talker+the+first+and+only+memoir&qid=1689845102&sprefix=code+talker+the+first+and+only+memoi%2Caps%2C229&sr=8-1">US Amazon
|
||
link</a>.</p>
|
||
<p>Really funny story he tells in the book, although some of the finer details are
|
||
from <a href="https://mishpacha.com/code-talkers/" class="uri">https://mishpacha.com/code-talkers/</a> as it’s been so long since I read it
|
||
and I don’t feel like picking the book up: it was so top secret that when they
|
||
were practising on a ship heading to Guadalcanal they were overheard on the
|
||
radio but because it was top secret the rest of the ship thought that the
|
||
Japanese cracked their communications. They were so concerned at first that they
|
||
shut down communication to listen in.</p>
|
||
<p>In fact (and this comes from the website): it would appear that one of the radio
|
||
operators overheard what he thought was Japanese. The ship’s officer thought so
|
||
too. Then one of the admirals informed the commanders that there were marines on
|
||
the ship who were communicating in their own language.</p>
|
||
<h3 id="but-how-did-it-work">But how did it work ?</h3>
|
||
<p>It had a two layer design. Let’s say someone intercepts the word for CODE:
|
||
<code>YIL-TAS</code>. In the case they don’t know what that Navajo word means they’re lost.
|
||
But <em>even if they do</em> they’ll instead interpret it as Navajo for PECK which means
|
||
nothing useful in the context of the war.</p>
|
||
<p>Not all words had this. For instance CONTROL: <code>NAI-GHIZ</code> is the literal
|
||
translation of CONTROL.</p>
|
||
<p>Some were rather close as well: ‘COUNTER ATTACK’ was <code>WOLTAH-AL-KI-GI-JEH</code>
|
||
which translates to ‘COUNTER ACT’. If a word was not coded they could spell out
|
||
the word which is exactly what I do here as well (as noted earlier, I think).</p>
|
||
<p>And on the subject of how it worked: I decided to not put a man page about this
|
||
submission because the language was so secret that they could not have a manual
|
||
either! I will explain the syntax though which really is all that’s needed; that
|
||
and the limitations/bugs section (though they’re not strictly bugs).</p>
|
||
<h3 id="the-navajo-code-talkers-dictionary">The Navajo Code Talker’s Dictionary</h3>
|
||
<p>The dictionary can be found at the US Navy history website <a href="https://www.history.navy.mil/research/library/online-reading-room/title-list-alphabetically/n/navajo-code-talker-dictionary.html">Navajo Code Talkers’
|
||
Dictionary</a>.
|
||
But alternatively you can find it in the file <code>dict</code>. Looking at this file will
|
||
be useful to help you understand some of the output assuming <code>dict</code> is not
|
||
encrypted itself (and of course it is but not as complicated as any of the Code
|
||
Talkers; see <a href="#how">explanation here</a>).</p>
|
||
<p>From the <a href="https://www.history.navy.mil/research/library/online-reading-room/title-list-alphabetically/n/code-talkers.html">Navajo Code Talkers Fact
|
||
Sheet</a>:</p>
|
||
<blockquote>
|
||
<p>When a Navajo Code Talker received a message, what he heard was a string of
|
||
seemingly unrelated Navajo words. The Code Talker first had to translate each
|
||
Navajo word into its English equivalent. Then he used only the first letter of
|
||
the English equivalent in spelling an English word. Thus, the Navajo words
|
||
“wol-la-chee” (ant), “be-la-sana” (apple) and “tse-nill” (axe) all stood for the
|
||
letter “a.” One way to say the word “Navy” in Navajo code would be “tsah
|
||
(needle) wol-la-chee (ant) ah-keh-di- glini (victor) tsah-ah-dzoh (yucca).”</p>
|
||
<p>Most letters had more than one Navajo word representing them. Not all words
|
||
had to be spelled out letter by letter. The developers of the original code
|
||
assigned Navajo words to represent about 450 frequently used military terms that
|
||
did not exist in the Navajo language. Several examples: “besh- lo” (iron fish)
|
||
meant “submarine,” “dah-he- tih-hi” (hummingbird) meant “fighter plane” and
|
||
“debeh-li-zine” (black street) meant “squad.</p>
|
||
</blockquote>
|
||
<p><strong>NOTE</strong>: from the above it might look like the code is wrong, where at least
|
||
one letter above is translated wrong. But at least some letters had more than
|
||
one translation and it was a matter of choosing one. However from my file, the
|
||
word for <code>YUCCA</code> was actually <code>TSAH-AS-ZIH</code> rather than <code>TSAH-AH-DZOH</code>. But if
|
||
you try that you’ll get <code>tsah-as-zih no-da-ih moasi moasi wol-la-chee</code>; to
|
||
translate that you can use <code>./prog.alt tsah-as-zih no-da-ih moasi moasi wol-la-chee</code>. The reason it works this way is because that is the <strong>literal</strong>
|
||
translation for <code>TSAH-AS-ZIH</code> which they used as the letter <code>Y</code>. Thus if you do
|
||
<code>./prog Y</code> you’ll get <code>TSAH-AS-ZIH</code> and if you do <code>./prog.alt TSAH-AS-ZIH</code>
|
||
you’ll get <code>Y</code>.</p>
|
||
<p>Additionally, if you try <code>./prog navy</code> you’ll get the output <code>tal-kah-silago</code> as
|
||
that <strong>is</strong> the word in their dictionary for <code>navy</code> (the literal translation was
|
||
<code>sea soldier</code>).</p>
|
||
<p><strong>NOTE</strong>: the alt program, which uses very similar code but has to be in an alt
|
||
file (<code>prog.alt.c</code>) due to the differences and because of encroaching on the
|
||
size restrictions of the contest (it’s also clearer and easier to maintain for
|
||
me even though the most important part is a simple macro of <code>1</code> or <code>0</code>), will do
|
||
these translations. However there are some oddities that will be explained later
|
||
in this file.</p>
|
||
<h3 id="examples">Examples</h3>
|
||
<p>The word ‘bikini’ is obviously not in the dictionary and not really relevant to
|
||
the IOCCC or the Second World War: at least not at the time; however there’s a
|
||
connection to that word just after the Second World War and believe it or not
|
||
it’s related to something from the war (yes really: see below!). So how do we
|
||
rectify this problem when using the program?</p>
|
||
<p>Well since we have the alphabet also we can just spell out words that are not in
|
||
the dictionary! Try:</p>
|
||
<pre><code> $ ./prog bikini
|
||
shush yeh-hes ba-ah-ne-di-tinin yeh-hes tsah yeh-hes
|
||
|
||
$ ./prog BIKINI
|
||
SHUSH YEH-HES BA-AH-NE-DI-TININ YEH-HES TSAH YEH-HES</code></pre>
|
||
<p>Okay but what about the letters? The translation for <code>shush</code> (literal
|
||
translation) is <code>bear</code> and they used it for <code>B</code>. So let’s try it:</p>
|
||
<pre><code> $ ./prog b
|
||
shush</code></pre>
|
||
<p>Okay to then translate it back:</p>
|
||
<pre><code> $ ./prog.alt shush
|
||
b</code></pre>
|
||
<p>Or to be less error prone (though this form will not work in every case - I’ll
|
||
highlight some examples later on):</p>
|
||
<pre><code> $ ./prog.alt $(./prog b)
|
||
b</code></pre>
|
||
<p>But here’s an interesting one…</p>
|
||
<pre><code> $ ./prog bear
|
||
shush dzeh wol-la-chee dah-nes-tsa</code></pre>
|
||
<p>How come if <code>shush</code> meant <code>bear</code> it doesn’t translate to just <code>shush</code>? Well
|
||
that’s because in the war dictionary there was no word for ‘bear’ directly, only
|
||
the literal translation (though there certainly were bears in the war including
|
||
the (in)famous <a href="https://www.britannica.com/animal/Wojtek-the-Bear">Wojtek</a>).
|
||
It is the indirection involved with the language and that made it so powerful.</p>
|
||
<p>Okay but for the ailurophiles like myself (not that I don’t love bears), what
|
||
about cats (such as the legend of <a href="https://en.wikipedia.org/wiki/Unsinkable_Sam">Unsinkable
|
||
Sam</a>, see <a href="#sam">amusing medical record
|
||
for Sam</a> below for a few laughs)? The word for <code>cat</code> was <code>moasi</code>.</p>
|
||
<p>So:</p>
|
||
<pre><code> $ ./prog c ; ./prog.alt $(./prog c)
|
||
moasi
|
||
c</code></pre>
|
||
<p>Of course you might want to print out the actual word so how to go about it?</p>
|
||
<pre><code> $ ./prog.alt $(./prog cat)
|
||
cat</code></pre>
|
||
<p>You can of course do this with <code>bear</code> as well.</p>
|
||
<pre><code> $ ./prog.alt $(./prog bear)
|
||
bear</code></pre>
|
||
<p>If you want to see the alphabet:</p>
|
||
<pre><code> $ for i in {a..z}; do ./prog "$i"; done</code></pre>
|
||
<p>…and you’ll see the alphabet that happens to be in the code, although that’s
|
||
in upper case.</p>
|
||
<h4 id="the-etymology-of-the-word-bikini">The etymology of the word ‘bikini’</h4>
|
||
<p>I said above that the garment ‘bikini’ has a namesake in a product of the Second
|
||
World War but what is it? Well there’s an atoll called Bikini in the Marshall
|
||
Islands that in 1946 the US exploded an atom bomb. The idea of the name of the
|
||
garment is its supposed ‘explosive’ effect. If you didn’t know this you now have
|
||
an interesting bit of trivia (you know, for the beaches or parties I’m sure you
|
||
go to … :-) ) where the bikinis are related by name to the atom bomb!</p>
|
||
<h3 id="difference-between-dict-and-dict.orig">Difference between <code>dict</code> and <code>dict.orig</code></h3>
|
||
<p>In the original dictionary there are some words that are followed by
|
||
parentheses with a letter in it. For instance:</p>
|
||
<blockquote>
|
||
<p>WITH BILH(W) WITH</p>
|
||
</blockquote>
|
||
<p>I am not sure but I believe that might have been another way to say the letter
|
||
W but since it could cause problems in output I have removed it from <code>dict</code>
|
||
(removed the parentheses and what was between them, I mean). It might also be
|
||
something else seeing as how there the alphabet is in another part of the file.
|
||
In any case we do not need it.</p>
|
||
<h3 id="what-about-input-files">What about input files ?</h3>
|
||
<p>Obviously it’d be ideal if one can encipher a file. The question was how to
|
||
specify that the input was a file. The prefix <code>+</code> seemed reasonable as usually
|
||
one wouldn’t write a <code>+</code> before a word without a space and it saves from having
|
||
to write an option parser (or adding to it). There is a subtle point that I
|
||
refer to in the limitations.</p>
|
||
<p>But what about error handling in file mode? If <code>getline()</code> returns < 0 (actually
|
||
it returns <code>-1</code> on error) it’s just skipped. I’ve never actually seen this happen but I
|
||
suppose it could. If it’s not a file no text is printed. Of course I don’t check
|
||
if it’s a text only file and it’s not even clear what should happen if it isn’t.
|
||
Like with <code>cat(1)</code> and many other tools, don’t feed non-text to this program!</p>
|
||
<p>File parsing is strange in output, however, possibly due to the shell but it
|
||
demonstrates how the strong the language was as a code, and how word boundaries
|
||
prove to be an issue.</p>
|
||
<p>See the <a href="#spaces">issue of spaces</a> for more details on spaces which is necessary
|
||
in order for the <code>English<->Navajo</code> bi-directional translations.</p>
|
||
<h3 id="questions-to-ponder-as-you-look-at-and-try-and-understand-the-output">Questions to ponder as you look at and try and understand the output</h3>
|
||
<p>Above we saw that the input <code>bikini</code> (see above for its relevance) gave the
|
||
value <code>shush yeh-hes ba-ah-ne-di-tinin yeh-hes tsah yeh-hes</code>.</p>
|
||
<p>Now try the input <code>BIKINI</code> and you’ll see that you will have the same output but
|
||
a different case (which was also shown). But can you get it to show other output
|
||
that’s also equally valid? An earlier version did this but it was changed to
|
||
save bytes. Can you guess how? This ability is a fun and very strong feature of
|
||
the language.</p>
|
||
<p>The alphabet had more than one translation per letter. But as I was pushing the
|
||
limits in size (especially considering I wrote this before the size restrictions
|
||
were lessened) I had to remove the extra letters. Also it is not clear to me
|
||
what letter should even be translated so after the size limit was lessened I did
|
||
not put them in. On the other hand I do have them in the file still, just not in
|
||
the source code. This also actually increases the obfuscation of the code though
|
||
so all the better.</p>
|
||
<p>Can you get the program to show literal translations instead? This is actually
|
||
much easier than it seems at least for words (including the alphabet) in the
|
||
dictionary file. Obviously this can’t be done for words not in the dictionary
|
||
which is a good reason to not have it; it was a misleading part of the design.</p>
|
||
<p>Why does</p>
|
||
<pre><code> ./prog.alt $(./prog +prog.c)</code></pre>
|
||
<p>show no spaces (or it shouldn’t) and a single line (I think it is only one
|
||
anyway) when</p>
|
||
<pre><code> ./prog +prog.c > foo
|
||
./prog.alt +foo</code></pre>
|
||
<p>does? What does it mean? As noted elsewhere it is unrealistic with the <a href="#spaces">spaces
|
||
issue</a> to expect an exact match.</p>
|
||
<p>Also: why does the first one seem to show (at least in my systems) what appears
|
||
to be files in the directory? Let’s just say it’s an ‘eavesdropping’ feature for
|
||
a language that was designed to be impossible to decrypt even if it was
|
||
overheard, even by the same side (on theme, you see)! Or we could just say it’s
|
||
an abuse of the shell, especially as it depends on the file’s content.</p>
|
||
<p><strong>HINT</strong>: the prog.c has the <code>*</code> and so the shell is interpreting that
|
||
character! Everything is normal in other words.</p>
|
||
<p>The fact is the file is contrary to what they had as they had to do it all in
|
||
their head - kind of like you typing the strings. I offer the prog.alt as a
|
||
helpful one but due to the way the language worked (including words having more
|
||
than one word) there will be oddities depending on how it was done. I did
|
||
workaround some of this when it comes to !isalpha() though.</p>
|
||
<p>As for the spaces seeming wrong in the second commands I explain why this
|
||
happens later in the <a href="#spaces">issue of spaces</a>; it’s not wrong. A quick
|
||
way-too-simplistic answer: it is because of how the alt code functions with word
|
||
boundaries. This is a feature, not a bug!</p>
|
||
<h3 id="changing-the-translation-to-convert-navajo-to-english">Changing the translation to convert Navajo to English</h3>
|
||
<p>This is very simple to do and it’s already done. Simply run <code>make alt</code> and use
|
||
the alt version of the program; it’ll translate translations back to English
|
||
(but <strong>not the literal translation!</strong>).</p>
|
||
<p>However it should be noted that as there’s not a good way to decide word
|
||
boundaries so for spaces in some invocations (not all) you have to specify a
|
||
literal space. For instance don’t do:</p>
|
||
<pre><code> ./prog.alt $(./prog b " " c)</code></pre>
|
||
<p>but instead do:</p>
|
||
<pre><code> ./prog b c > foo
|
||
./prog.alt +foo</code></pre>
|
||
<p>The former might show <code>bc</code> and the latter will show a space and possibly a
|
||
newline.</p>
|
||
<p>At various points I had it where you could do the first but it was a battle and
|
||
it did not seem worth fighting when I could spend more time on other things like
|
||
obfuscating it and submitting it. It also used to read from stdin as an option
|
||
but this seemed not very useful and in some cases caused (depending on the
|
||
file’s contents) the program to want to read from stdin (as I already gave an
|
||
example of the shell interfering I won’t get into this more). It’s not a
|
||
limitation and besides they did this all in their head; they had no files or
|
||
even computers as we know it.</p>
|
||
<p>You might find quotes can cause strange output in some cases (or did - not sure
|
||
now). Even worse what happens if the Navajo word translates to one of the
|
||
military words but you don’t want that? Nothing we can do about that! I don’t
|
||
even think <strong>they</strong> could have done something about that. That’s the multiple
|
||
layers of the system/code.</p>
|
||
<h3 id="literal-translation-notes">Literal translation notes</h3>
|
||
<p>I already hinted at this and asked you to ponder this: but there are actually
|
||
other ways you can configure this program so it translates between different
|
||
lists. You could (but this is pointless because it isn’t authentic then) have it
|
||
translate of Navajo to literal meaning. I was seriously considering taking this
|
||
out as I don’t even like the idea (due to the fact it would dishonour the
|
||
language) but technically it’s possible with some modifications to the code.</p>
|
||
<h3 id="notes-limitations-of-the-language">Notes / Limitations (of the language)</h3>
|
||
<p>The dictionary file has to be in a specific format. I don’t really see this as a
|
||
problem but it’s worth pointing out that it won’t work if the dictionary file is
|
||
in an invalid format. It’s not necessarily what it seems! But it does also allow
|
||
for further obfuscation so it seemed like a good idea.</p>
|
||
<p>See the <a href="#how">how the dictionary file works</a> if you’re curious.</p>
|
||
<p>Actually if you figure it out you can use this entry to translate other
|
||
languages as well! Kind of. As you’ll see in the file it’s not quite as it
|
||
seems. You can indeed make it translate other languages (notwithstanding
|
||
diacritics - or actually that might be possible too but not sure of it) but you
|
||
have to do a bit of work first. That especially goes because the alphabet (for
|
||
words not in the dictionary) would still be spelt out as Navajo Code Talker
|
||
language!</p>
|
||
<p>Something else about the Navajo language and the case of letters. As I don’t
|
||
know Navajo I don’t know if something I did is strictly correct. As the
|
||
dictionary had everything capitalised I took some liberty in not doing this in
|
||
that if the input letter or word is lower case it’s made all lower case; but if
|
||
it’s capitalised only the first letter for each word is capitalised at least for
|
||
the words in the dictionary (I think I did that). This goes for words in the
|
||
dictionary.</p>
|
||
<p>An example: in German all nouns are capitalised; this is why <code>ich</code> (I) is only
|
||
capitalised at the beginning of a German sentence (no, ‘I’ is not a noun). But
|
||
this was also due to the difference in lengths and keeping track. The issue of
|
||
length of words will be brought up again.</p>
|
||
<p>In the case of titles this might be wrong but I wanted it to read naturally
|
||
which (if translated back to English - not the literal translation) would be
|
||
better if it preserves the case of the input. This does mean acronyms won’t be
|
||
all capitalised at least if it’s in the dictionary (can you figure why I can’t
|
||
do that?) but I deem this an immaterial technicality.</p>
|
||
<p>Obviously if the dictionary file is missing or invalid format the words will not
|
||
work. In this case the program will just spell each word (it might also show an
|
||
error but continue to spell it out - for instance if you move the file to
|
||
something else).</p>
|
||
<p>This is not the fault of the program but the language as well as the environment
|
||
and/or user. Well it might do the individual letters right but I’m not sure of
|
||
this; it might even do something funny for all I know.</p>
|
||
<p>There were spelling errors in the dictionary. For instance they had <code>straff</code>
|
||
which I can only assume was meant to be <code>strafe</code>. Perhaps this is wrong but so
|
||
is <code>straff</code>. Okay actually <code>straff</code> is a German word but it was English, not
|
||
German.</p>
|
||
<p>Newlines might not be printed well unless reading from a file with the <code>+</code>
|
||
prefix. They might but might not. It would seem they won’t be given that at the
|
||
command line as there aren’t newlines per se. As I noted in the file mode
|
||
section the alt code only prints literal spaces but it also just passes
|
||
non-Navajo words as is.</p>
|
||
<p>On the other hand one can mix files and input at the command line. Note that
|
||
<code>clearerr()</code> is called so one should be able to use the file again though I do
|
||
not guarantee this part (given that it’s closed it’s probably especially not
|
||
even needed though as it’s just opened again).</p>
|
||
<p>Due to the nature of the processing if one does specify a <code>+</code> before text that
|
||
is not a file (user error) and no input following that there will be a blank
|
||
line (might be two, not sure) and then nothing else will be printed.</p>
|
||
<p>This is because the <code>+</code> is separate from the word itself; the letters constitute
|
||
a word but the <code>+</code> is not even part of the Navajo language (in the Code Talking
|
||
sense (if at all?)). The same goes for other <code>!isalpha()</code> chars except they will
|
||
be printed with words that are not in the language (and I think even those that
|
||
are - that was a later addition if so). There’s a function that does
|
||
an operation similar to <code>strcasecmp()</code> but which ignores <code>!isalpha()</code> chars so
|
||
that <code>test.</code> and <code>.test..</code> are equal (in comparison, not in output). That’s used
|
||
in the case of a dictionary word like <code>B</code>: hence <code>./prog ..B..B</code> should show
|
||
<code>..SHUSH ..SHUSH</code> (observe the space after the first one - that’s a feature and
|
||
is shown elsewhere too, including <a href="#spaces">the issue of spaces</a>).</p>
|
||
<p>I believe that the way it’s done (with printing the characters too) one can do
|
||
<code>./prog.alt $(./prog -code)</code> and get <code>-code</code> (this was no always possible but I
|
||
believe I added this later on - a quick test suggests it).</p>
|
||
<p>Some of the military words are more than one word which can cause a problem;
|
||
what could be done? Actually there is a way here but not when reading from
|
||
files.</p>
|
||
<p>Here’s an example of the two:</p>
|
||
<pre><code> $ ./prog 'COMMANDING OFFICER'
|
||
Hash-kay-gi-na-tah
|
||
|
||
$ echo commanding officer > test
|
||
|
||
$ ./prog +test
|
||
moasi a-kha be-tas-tni be-tas-tni wol-la-chee tsah chindi yeh-hes tsah jeha a-kha chuo chuo yeh-hes moasi dzeh dah-nes-tsa</code></pre>
|
||
<p>What happened? It reads in the file delimited by lines and delimits each by
|
||
spaces. It does try reading it word by word (by the shell) but it can’t handle
|
||
multiple words as one word unless it’s in the dictionary and one word in the
|
||
shell. It needs it to be a single word, hence the <code>'</code>s. This will work fine
|
||
because it simply leaves them untouched:</p>
|
||
<pre><code> $ ./prog.alt +test
|
||
commanding officer</code></pre>
|
||
<p>This will also work:</p>
|
||
<pre><code> $ ./prog 'commanding officer' > test
|
||
|
||
$ ./prog.alt +test
|
||
commanding officer
|
||
</code></pre>
|
||
<p>The extra newline is added by the program.</p>
|
||
<p>There is a solution to this but it makes it hard to use the program (I think). My
|
||
understanding is the dashes were only used in the Code Talking so: make the
|
||
multi word military terms not space delimited but dash delimited like the Navajo
|
||
language. This would require the input to follow the same format though (e.g.
|
||
commanding-officer) which might not always be the way it is and would put a
|
||
burden on the user as well. This is actually very easy to change though. Perhaps
|
||
it would work better than I expect but it is unnatural and also not the way
|
||
their dictionary even has it - there is no dash in the ‘commanding officer’.</p>
|
||
<p>Whereas they could control the boundaries, we cannot, and even though they wrote
|
||
down the translation, they were familiar with the language and they added spaces
|
||
where necessary. Unfortunately in order to translate we have to have some kind
|
||
of delimiter and what would it be if not space?</p>
|
||
<p>Mostly the problem is when trying to decipher an already enciphered string - due
|
||
to word boundaries. Sometimes (not now) adding a literal <code>" "</code> as a word
|
||
separator would help but as I think I said before it was a battle, where it
|
||
might break one thing to fix another, and I got tired of trying to make it
|
||
perfect as it probably shouldn’t even be perfect due to the nature of the
|
||
language. Mostly this is if you do it like this:</p>
|
||
<pre><code> $ ./prog.alt $(./prog b " " c)
|
||
bc</code></pre>
|
||
<p>This works fine though:</p>
|
||
<pre><code> $ ./prog b c > foo
|
||
|
||
$ ./prog.alt +foo
|
||
b c
|
||
</code></pre>
|
||
<p>That might or might not be the shell messing things up.</p>
|
||
<p>What about not spelling out words not in <code>dict</code> (leave them untouched)? This
|
||
could be done easily but it wouldn’t be authentic so I’ve not done it (in
|
||
prog.c). On the other hand:</p>
|
||
<pre><code> $ ./prog.alt a b
|
||
ab
|
||
|
||
$ ./prog.alt a " " b
|
||
a b</code></pre>
|
||
<p>work fine because there is no translation being done!</p>
|
||
<h3 id="portability">Portability</h3>
|
||
<p><strong>DON’T EVEN THINK ABOUT</strong> using this on non-ASCII systems; it heavily abuses
|
||
arithmetic on strings and other calculations. It might require two’s complements
|
||
as well but I’m not concerned about either as other systems are rare now, if
|
||
that’s the case - I am not even sure of what all I did, a reasonable symptom of
|
||
writing confusing code a long time ago.</p>
|
||
<h3 id="bugs-mis-features-limitations">Bugs / Mis-features / Limitations</h3>
|
||
<p>There are a few things I’ve not touched upon in other sections that might appear
|
||
to be bugs and some that some might argue as bugs but might be called features
|
||
as well.</p>
|
||
<p>Here’s a fun one. Why:</p>
|
||
<pre><code> $ ./prog include
|
||
el-tsod
|
||
|
||
$ ./prog '#include'
|
||
#el-tsod
|
||
|
||
$ ./prog b
|
||
shush
|
||
|
||
$ cat foo
|
||
#include
|
||
b
|
||
#yeh-hes tsah moasi nash-doie-tso no-da-ih chindi dzeh
|
||
shush</code></pre>
|
||
<p>In other words, why does it spell it out words but letters seem to be untouched
|
||
(or some - are all?) when reading from a file?</p>
|
||
<p>This is a challenge I am giving you for you to figure out when it comes to file
|
||
mode! Can you actually get it to do what else you might (or might not) prefer?
|
||
And before you say ‘bug!’: would I really even offer file mode when they did not
|
||
do this with computers (they did it in their head), if this was a bug? I didn’t
|
||
think so :-) Carrying on…</p>
|
||
<p>The OS will have to deal with some memory leaks; some memory is freed but I was
|
||
not able to free all due to the large amount of data (I could have just read it
|
||
all in but I wanted to show that I was not trying to abuse the size limit - even
|
||
though other entries in the past have read in dictionary or similar files) in
|
||
the code along with needing more bytes for obfuscation and so reaching the size
|
||
limit.</p>
|
||
<p>It was even worse when the size limit was more strict (I started this
|
||
before that happened and then put it out of sight for a while). Memory from
|
||
<code>getline(3)</code> should be taken care of but the linked list and its associated
|
||
memory is/are not freed. Actually below you’ll see in some cases a memory error
|
||
occurred but that no longer happens (except due to the bug <strong>in <code>getline(3)</code>
|
||
itself</strong>).</p>
|
||
<p>And on that subject of <code>getline(3)</code>: there is actually a bug in it, at least in
|
||
some systems; this was actually <a href="https://inbox.sourceware.org/glibc-bugs/bug-28038-131@http.sourceware.org%2Fbugzilla%2F/">reported as a
|
||
bug</a>
|
||
(not by me but someone else). It’s reported by valgrind and unfortunately
|
||
adding a workaround broke the output. It was driving me crazy until I finally
|
||
tracked it down; I was sure my code there was fine but I could not discover it
|
||
until I dug deeper and saw it was a reported issue.</p>
|
||
<p>Yes I realise that bug report is from 30 June 2021 and it’s in status
|
||
‘UNCONFIRMED’ but the report describes the exact same symptoms.</p>
|
||
<p>Anyway valgrind will (did?) if reading from an affected file report:</p>
|
||
<pre><code> Uninitialised value was created by a heap allocation
|
||
==1271819== Conditional jump or move depends on uninitialised value(s)</code></pre>
|
||
<p>The function (<code>Y()</code>) is the function that does the comparison without caring
|
||
about non-alphabetical characters (I think?). It doesn’t seem to be that I do not use
|
||
<code>strdup()</code> prior to the <code>strtok()</code> and in fact using it <strong>caused</strong> a read error so
|
||
that was obviously the wrong choice as well (plus it’s unnecessary in this case
|
||
and it allowed more functionality and obfuscation). If I recall correctly that
|
||
was the <code>a->A</code> prior to using <code>strtok()</code>.</p>
|
||
<p>And besides the bug report for <code>getline(3)</code> it works fine if there is text on
|
||
the last line. And like I said I can add a workaround which if the length read
|
||
is > 0 zero out the <code>buf[len-1]</code> but this breaks the output of the program so I
|
||
don’t do that. Actually as I recall the error still happened if I checked the
|
||
length > 1! Nonetheless it breaks the output if it’s ‘fixed’.</p>
|
||
<p>Multiple systems have not shown any behavioural issues <strong>unless</strong> I add that
|
||
workaround. In any case valgrind reports no additional issues.</p>
|
||
<p>Now: why does the alt version sometimes show words that are English in English?
|
||
It’s not actually a bug but maybe it would appear to be. I already showed this
|
||
and gave a brief explanation but there are also other occasions it can occur. It
|
||
can also depend on the input/command line itself (and for instance because it’s
|
||
translating back to English so if it’s English there is nothing to do - which
|
||
brings up an interesting quest of how does it know that?).</p>
|
||
<p>A command line that does not make sense:</p>
|
||
<pre><code> $ ./prog.alt b $(./prog)
|
||
b</code></pre>
|
||
<p>Actually what is happening is the <code>./prog</code> part is
|
||
empty string so <code>prog.alt</code> is simply printing all it can print, no translation
|
||
at all (notice the <code>b</code> prior to the <code>$(./prog)</code>! Try breaking it up:</p>
|
||
<pre><code> $ ./prog.alt b
|
||
b</code></pre>
|
||
<p>Why? Well again there is no translation to do! Now what does <code>./prog</code> by itself
|
||
do? It is an empty string (or maybe just a newline), as noted. Thus this does
|
||
make sense:</p>
|
||
<pre><code> $ ./prog b
|
||
shush
|
||
$ ./prog.alt $(./prog b)
|
||
b</code></pre>
|
||
<p>(which I’ve shown before.) Is this a bug?</p>
|
||
<pre><code> $ ./prog.alt hat
|
||
hat</code></pre>
|
||
<p>Nope. It’s because there’s no translation to translate back into English so it
|
||
just passes it as is.</p>
|
||
<p>Here’s a translation:</p>
|
||
<pre><code> $ ./prog.alt $(./prog code file)
|
||
codefile</code></pre>
|
||
<p>Uh oh! What happened? Well I already explained this part (and much more detail
|
||
in the <a href="#spaces">issue of spaces</a> section). Fixing this caused
|
||
other things to break and going back and forth with the twisted code was doing
|
||
my head in so I had to stop. It was at one point possible to do <code>./prog code " " file</code> and at one point it had the space there but that made reading from files,
|
||
which seems more useful to me, have bad output. Note the issue here: both <code>code</code>
|
||
and <code>file</code> are actually in the language: yes when I say they had no files I
|
||
meant no files to read from like we have on our computers.</p>
|
||
<p>It is possible to do that
|
||
directly though as I showed (earlier I think). This will work though:</p>
|
||
<pre><code> $ ./prog.alt $(./prog code.file)
|
||
code.file</code></pre>
|
||
<p><strong>THIS</strong> works too:</p>
|
||
<pre><code> $ ./prog.alt shush " " chuo
|
||
b f</code></pre>
|
||
<p>as does:</p>
|
||
<pre><code> $ ./prog.alt +foo
|
||
b f</code></pre>
|
||
<p>(assuming <code>foo</code> has the right content of course.)</p>
|
||
<p>As a consequence of how the words have to be tokenised you have to be careful if
|
||
you want a translation. For instance don’t do:</p>
|
||
<pre><code> ./prog code.file
|
||
moasi a-kha chindi dzeh .chuo yeh-hes nash-doie-tso dzeh</code></pre>
|
||
<p>(but notice how the command <code>./prog.alt $(./prog code.file)</code> does work where it
|
||
‘translated’ it back to <code>code.file</code> - can you figure out what is <strong>really</strong>
|
||
happening there?). This is because there is nothing breaking the word apart. The
|
||
<code>Y()</code> function does check for matches ignoring <code>!isalpha()</code> but what is it
|
||
comparing against? Again if a known delimiter could be specified this could be
|
||
resolved but trying to do that would assume the user’s intentions. It is better
|
||
to require a space than to do that. You can do this instead:</p>
|
||
<pre><code> $ ./prog code . file
|
||
yil-tas . ba-eh-chez</code></pre>
|
||
<p>or even better:</p>
|
||
<pre><code> $ ./prog code file
|
||
yil-tas ba-eh-chez</code></pre>
|
||
<p>BTW: don’t try this:</p>
|
||
<pre><code> ./prog +prog.c > foo
|
||
./prog.alt +foo</code></pre>
|
||
<p>without anticipating an extra space issue. Unfortunately this is <strong>necessary</strong>
|
||
because the only sane delimiter is a space. In particular, if you take a look at
|
||
the file <code>foo</code> (after the <code>./prog +prog.c > foo</code>) you might pick up on why this
|
||
happens. In fact somewhere in this file I showed the same thing at play (or I
|
||
think I did): it’s a matter of word boundaries with the letters; since the words
|
||
have to be spelt out the spaces are there! That is a feature, not a bug.</p>
|
||
<p>Frankly I prefer the look here though I’ll return to that idea later on.</p>
|
||
<p>Without the space the match cannot occur (although an example above would seem
|
||
to belie that, which just adds to the obscurity of my program).</p>
|
||
<p>There was a way I played with but it was too cost prohibitive in size, it was
|
||
problematic and I could not determine all edge cases. Besides like I said and
|
||
demonstrated the spaces <strong>need</strong> to be there (with more space it <strong>might</strong> be
|
||
possible but that is not the case).</p>
|
||
<p>Other cipher systems work differently and don’t rely on two sets of ways to go
|
||
about it - it’s one or the other (there might be exceptions but for instance
|
||
rot13 and Enigma both have a one-to-one mapping - okay the Enigma had many
|
||
possible combinations for the same word depending on what came before it but you
|
||
know what I mean; as long as the settings are the same you can derive the same
|
||
result). As I note elsewhere they actually had more than one word for letters
|
||
too and I have made them in an array which means that not all translations are
|
||
even used.</p>
|
||
<p>The real trouble, basically, is that a word can be spelt out OR have a
|
||
translation so a choice had to be made. I chose to spell things out without
|
||
having to write an even more messed up parser (though as I note later on I tried
|
||
it it just caused even more problems than it was worth).</p>
|
||
<p>So this is a feature, not a bug!</p>
|
||
<p>You can summarise the above with the following statements:</p>
|
||
<ul>
|
||
<li>When translating to Navajo (prog, X=0) if the word is not in their dictionary
|
||
it will spell it out, each letter (a word or words) being separated by a space.</li>
|
||
<li>When translating to Navajo (prog, X=0) if the word IS in their dictionary
|
||
print out the Navajo word (sometimes with a <code>-</code> in it).</li>
|
||
<li>When translating Navajo to English (prog.alt, X=1) with a known Navajo word
|
||
(in the Second World War sense) the translation is printed without spaces, as
|
||
the words are on a space boundary and since it’s not a letter-by-letter basis
|
||
with known translations, there is a single word (or words in some cases, maybe,
|
||
although I don’t recall that) printed (though depending on input it might or
|
||
might not have the space there - I showed an example above).</li>
|
||
<li>When translating Navajo to English (prog.alt, X=1) but there actually is no
|
||
original translation, it prints each letter separated by a space (well if you
|
||
have an explicit space there like I showed above). If you can figure out why
|
||
this happens you have a bit better understanding of the function <code>I()</code>. Okay
|
||
actually one can do things like <code>./prog.alt $(./prog book)</code> and get <code>book</code> when
|
||
<code>./prog book</code> will print out each letter but you saw what I mean here.</li>
|
||
<li>Because of having to deal with <code>!isalpha()</code> characters in input (at least to
|
||
be the most user-friendly - I could have avoided it to make it more like ‘the
|
||
real thing’ but that would have prevented other features) the <code>Y()</code> function
|
||
will ignore those characters (though in the front of the word <code>I()</code> should print
|
||
it). Also if a translation is found it might remove some of the characters that
|
||
are not part of that translation (or it did - it might be different now but as
|
||
they didn’t have to deal with files or grammar, doing it all in their head very
|
||
quickly, the fact it sometimes does it fine is a kind afterthought on my part).</li>
|
||
</ul>
|
||
<p>Oh and as far as tokenisation goes: it occurred to me that even this will not
|
||
always work. I was playing with the idea of having output tab separated: then I
|
||
could use <code>strtok()</code> on the input and do it that way. It was looking somewhat
|
||
promising and then it occurred to me that while this might help with the
|
||
program’s output (though making it harder to read for most people) it won’t help
|
||
if someone puts in the string manually! So there really is no way to deal with
|
||
this satisfactorily in ever case and trying to do so actually takes away from
|
||
the brilliance of the language. And we don’t want that, do we? :)</p>
|
||
<p>Spaces shown now are necessary and in the case where spaces are not shown but it
|
||
seems like they should be, that is an unfortunate technicality that’s a feature,
|
||
not a bug.</p>
|
||
<p>Actually if the spaces are not precisely correct it can cause gibberish to
|
||
appear and the fact is the only gibberish we see is the language, and it’s only
|
||
gibberish if you don’t know the language!</p>
|
||
<p>To the Code Talkers the issue of spaces and grammar was entirely inconsequential
|
||
anyway because it was done all in their head, kind of like as you’re reading
|
||
this very sentence (even if you read it out loud the spaces and grammar are only
|
||
visual aids to help you so
|
||
<code>youdonthavetoreadsomethinglikethisuntilyougetaheadache</code> - as most people,
|
||
although I am a rare exception, cannot read well without spaces between words)
|
||
and therefore they are inconsequential to us too.</p>
|
||
<p>The language was not to be understood by any others and it was very successful
|
||
at that; thus you do need to expect some oddities when it comes to printing
|
||
words that are not in their dictionary. This is a feature of the program and it
|
||
can actually result in some fun output! This is part of the obscurity of the
|
||
program and the language as well.</p>
|
||
<p>This is also why I tried to put a lot of whitespace in the program code, just to
|
||
really drill it into your head that spaces are both important and not important,
|
||
depending on the context, and depending on what is needed. Since you won’t be
|
||
speaking out the code, spaces don’t matter any more than they matter in the
|
||
output. In other words, spaces don’t matter. But they also matter as they are
|
||
necessary for translation to work.</p>
|
||
<p>For more details on the real problems with the spaces and why only alt code
|
||
might be considered, see later in this file in the <a href="#spaces">spaces issue</a>
|
||
section.</p>
|
||
<h3 id="obfuscation">Obfuscation</h3>
|
||
<p>This section might not be complete. This is because I added a heavily commented
|
||
<a href="deobfus.c">deobfus.c</a> file and although it’s not technically deobfuscated the
|
||
comments might help explain some of it. Though as you’ll see even some of it I’m
|
||
not sure about; by looking at this file you will probably curse me and you might
|
||
have some kind of respect (or awe) but you’ll also see just how twisted this
|
||
code is (and how messed up I am, presumably). It is truly awful and I’m
|
||
extremely proud of it. I don’t think I could do this again as I have no bloody
|
||
idea how I did it. I have no idea how I came up with the calculations let alone
|
||
anything else that’s obscure.</p>
|
||
<p>Please, if you do read it, and I know the judges will at least, take care and
|
||
maybe eat some great chocolate (like the final comment suggests) after doing so
|
||
as you might need it. It was really hard for me to go through and I had to go
|
||
through it more than once after making some significant changes (and fixes) to
|
||
the code (when printing files it used to add an extra space to the beginning of
|
||
lines after the first line, for example) I have provided the file as the judges
|
||
now appreciate educational value and also because by commenting it I could show
|
||
the obfuscation techniques in the code itself, plus it is so twisted it amuses
|
||
me (sorry if I stress anyone out). Nevertheless I will try and list a few
|
||
things, some of which were not mentioned in the code (I think).</p>
|
||
<p>I might also add that if there is some inconsistency it came later on though I
|
||
don’t think there is any.</p>
|
||
<p>The <code>dict</code> is kind of obfuscated. Not really but kind of (see <a href="#how">how to unravel
|
||
it</a> if you wish to know). Even after you figure it out though it won’t
|
||
help you understand the program.</p>
|
||
<p><code>main()</code> is rather funny. Who cares about ‘possible’ misuse of comma operator,
|
||
unused parameters and bitwise negation of a boolean expression if it hides
|
||
details? Comma operator is used elsewhere as well but who cares? Actually the
|
||
great thing, which is discussed in the Compiling/Warnings section, some warnings
|
||
actually, if fixed, <strong>WOULD BREAK THE CODE</strong> (and none of them are relevant in any
|
||
case); some can be silenced by casting to void but even in some of those cases
|
||
the warning is incorrect in what it’s saying.</p>
|
||
<p>That includes ‘unused value’ or should I say ‘“unused” value’?</p>
|
||
<p>The array <code>B</code> won’t make any sense to most people. How I use it probably is not
|
||
exactly clear either. Earlier on I had words of the Navajo language as variable
|
||
and function names but I couldn’t do everything I did without changing it; in
|
||
fact when I originally wrote it before the change in size limits the program was
|
||
pushing the limits and obfuscation was not as good and there were several bugs
|
||
to fix as well, leaving virtually no space for obfuscation!</p>
|
||
<p>But of course single letter names don’t convey anything either.
|
||
But before I can discuss anything else I better discuss the anonymous struct
|
||
that holds state that can vary from function to function. Here are some
|
||
examples.</p>
|
||
<pre><code> F((c=((~~!!~!9u|2**"9"-15u/ *"0"-2u)<<~~!~!~9u),c&=9u,&(struct a){ .l=1, .s=a[c],.v= { &w, &w } } ));
|
||
|
||
Z(&(struct a){ .v = { t, I } ,.l=c, .h=a} );
|
||
|
||
if &lpar;a->v[2]&lpar;&&lpar;struct a&rpar;{ .w=a->a->w, .c=a->x} &rpar;&rpar;
|
||
|
||
c->w = strdup&lpar;X?a->v[a->l]&lpar;&&lpar;struct a&rpar;{ .s=a->S} &rpar;:a->v[a->e==0]&lpar;&&lpar;struct a&rpar;{ .s=a->N} &rpar;&rpar;;
|
||
c->c = strdup&lpar;X?a->v[1]&lpar;&&lpar;struct a&rpar;{ .s=a->N} &rpar;:a->v[a->l]&lpar;&&lpar;struct a&rpar;{ .s=a->S} &rpar;&rpar;;
|
||
|
||
while (a->S)
|
||
if ((a->y=strdup(a->S))) {
|
||
(*a->v)(&(struct a){ .v[2]=Y, .x=a->y} ); a->S = strtok(0, " \t"); free(a->y); a->y=0;
|
||
</code></pre>
|
||
<p>These are truly nasty beyond the look because what it does is it allows me to
|
||
have the same data in a struct (outside the struct <strong>and</strong> in a sense in the
|
||
struct) do <strong>different things in different places</strong>. In fact the only reason I need
|
||
the two variables <code>struct a *f</code> an <code>struct a *c</code> is because of the linked list;
|
||
everything else is anonymous in the functions!</p>
|
||
<p>Here are some funny statements / expressions:</p>
|
||
<pre><code> o = *"";
|
||
|
||
s=z+-*"1"-*"1"- -97,L=putchar(!s&&isupper(a->x[0**"z"])?a->a->c[s]:tolower(a->a->c[s]));
|
||
|
||
c = calloc(1**"0"-47, sizeof *c);
|
||
|
||
for (a->a = f, z = 0**"1"; a->a; a->a = a->a->e)
|
||
|
||
for (z = 2/ *"z", s=1+0**"1"; z[a->x]; ++z)
|
||
|
||
for (J = *"1"-*"1"; J < 26 && B[J][X?1/ *"1"+s/
|
||
*"1"+1/ *"1"+s/ *"1"+1+(s-s)**"1"+(s*(s-s))**"1":((((s-1)**"1")**"1")**"1")**"1"]; ++J)
|
||
|
||
|
||
(((*a->h[--a->l]=='e'-':')&&(*a->v)(&(struct a){ .v[0]=I, .s=((a->l)[a->h])+1} )
|
||
&&++a->l&rpar;||&lpar;a->v[1]&lpar;&&lpar;struct a&rpar;{ .v[2]=Y,.x=&lpar;&lpar;a->l&rpar;[a->h]&rpar;} &rpar;,++a->l&rpar;&rpar;; if &lpar;g&rpar; puts&lpar;""&rpar;; }
|
||
|
||
if (*B[J][0+*"1"-*"1"] == toupper(z[a->x]))
|
||
|
||
|
||
for (k = (s*2)**"9"-171+*"9"; H=B[J][X?*"1"-49:s/ *"1"+s/ *"1"+1/ *"1"+(s*s*s)][k]; ++k)
|
||
</code></pre>
|
||
<p>And you really thought you couldn’t mix arithmetic and strings in C? Now that you
|
||
know better can you tell me what’s going on or keep track of what it’s doing? In
|
||
some cases it’s actually nested but with this there are few numbers that are
|
||
what they appear to be.</p>
|
||
<p>Some of these are really funny (and a bit nasty) because if you try removing
|
||
spaces you’ll turn the expression into a comment! If you need help in
|
||
unravelling these, I gave it my best go in <a href="deobfus.c">deobfus.c</a>; but as it
|
||
says there some of it I really cannot parse well - some of it seems so wrong and
|
||
yet what looks ‘right’ is wrong (for instance it looks like <code>-1</code> will be the
|
||
index in an array but trying to ‘fix’ it will break the code).</p>
|
||
<p>Fun fact: in C, the following are both legal:</p>
|
||
<pre><code> char **c;
|
||
|
||
char * *c;</code></pre>
|
||
<p>(in particular, the whitespace is allowed, although in <strong>some</strong> cases it can cause
|
||
unexpected output). So in my code depending on the command, for example:</p>
|
||
<pre><code> ./prog.alt $(./prog +prog.c)</code></pre>
|
||
<p>will show funny output (remember also it ends up passing <code>*</code> to the shell!)
|
||
whereas:</p>
|
||
<pre><code> ./prog.alt +prog.c</code></pre>
|
||
<p>won’t.</p>
|
||
<p>As for the <code>*</code> in the code causing the shell to show files in the directory
|
||
interspersed with other text (which I think is hilarious but not the fault of
|
||
the program) there are other funny things that can happen due to the shell and
|
||
command line. For instance I have at times seen <code>returnreturn</code>!</p>
|
||
<p>Consider this a fun Easter egg, if your system is affected, that I chose to keep
|
||
because the formatting was more important and output is actually correct when
|
||
not abusing the shell. Considering too I was able to spell out <code>IOCCC</code> in the
|
||
formatting of the code which I might not have been able to do as easily is
|
||
another reason for this.</p>
|
||
<p>Compress some if/while loops with <code>&&</code> and comma operator. The biggest example
|
||
is the while loop in <code>Z()</code> which acts on the argc/argv of <code>main()</code> (and the loop
|
||
condition increments, then the body immediately undoes the increment and then at
|
||
the end redoes the increment so that at the next pass the <code>c</code> (argc) is back to
|
||
where it was left at the start of the loop body) which is a single statement but
|
||
which would normally be several. Also in <code>Z()</code>: why is this valid?</p>
|
||
<pre><code> while (a->h[a->l++])</code></pre>
|
||
<p>How is <code>a->h[a->l]</code> set to a safe value? Well in <code>main()</code>:</p>
|
||
<pre><code> F((c=((~~!!~!9u|2**"9"-15u/ *"0"-2u)<<~~!~!~9u),c&=9u,&(struct a){ .l=1, .s=a[c],.v= { &w, &w } } ));
|
||
Z(&(struct a){ .v = { t, I } ,.k=0, .l=c, .h=a, .j=f} );</code></pre>
|
||
<p>The <code>c</code> (which is the <code>argc</code>) is set to the correct value. Of course that
|
||
expression is insane. The <a href="deobfus.c">deobfus.c</a> explains just how nasty this
|
||
really is, particularly for the <code>Z()</code> function.</p>
|
||
<p>Can you explain this behaviour?</p>
|
||
<pre><code> $ echo $(dirname $(type -P file)/$(./prog file))
|
||
/usr/bin/file
|
||
|
||
$ $(echo $(dirname $(type -P file)/$(./prog file))) prog.c
|
||
prog.c: c program text, ASCII text</code></pre>
|
||
<p>when this happens?</p>
|
||
<pre><code> $ ./prog file
|
||
ba-eh-chez</code></pre>
|
||
<p>And yes here again <code>file</code> is used but not in the way we know it on our computers.</p>
|
||
<p>What is:</p>
|
||
<pre><code> putchar(('\0'+'!'-1));</code></pre>
|
||
<p>? It is a screwy call to <code>putchar(' ');</code>. Obviously this requires ASCII but that
|
||
should be obvious with some of the other ways the code works too. The fun thing
|
||
is how I formatted the code I was able to make it look like I did
|
||
<code>putchar('\0')</code> - or at least it starts to look that way!</p>
|
||
<p>All the functions besides main return a <code>char *</code> and take a <code>struct a *</code>. But
|
||
rather than poison the structs needed for operation, the functions are called
|
||
with anonymous <code>struct a *</code>s with the specific values set in the function call
|
||
themselves. For instance the following will create call a function <code>foo</code> that
|
||
takes a <code>struct bar *foo</code> with an <code>int baz</code> set to <code>1</code>:</p>
|
||
<pre><code> int foo(struct bar *foo)
|
||
{
|
||
return foo?foo->baz:-1;
|
||
}
|
||
|
||
foo(&(struct bar){.baz=1});</code></pre>
|
||
<p>Why make extra objects when we can use anonymous objects, especially when it the
|
||
latter is far more obscure and much harder to keep track of? And why poison the
|
||
structs when I can poison your mind’s ability to parse the code? Thank you very
|
||
much to the C standards body for what probably was a terrible idea (except for
|
||
the IOCCC)! (Though I can think of a few cases it might be useful it’s clearly
|
||
bound to be abused - and I believe this is the first time in the contest’s
|
||
history it was though I might be wrong.)</p>
|
||
<p>A special mention is due I think as well. I noted this in the
|
||
<a href="deobfus.c">deobfus.c</a> file a bit but I want to elaborate a bit more. In
|
||
<code>main()</code> I do something extremely nasty so that <code>Z()</code> (which is also extremely
|
||
nasty, see below) works right without accessing invalid memory.</p>
|
||
<p>The function call:</p>
|
||
<pre><code> F((c=((~~!!~!9u|2**"9"-15u/ *"0"-2u)<<~~!~!~9u),c&=9u,&(struct a){ .l=1, .s=a[c],.v= { &w, &w } } ));</code></pre>
|
||
<p>does a number of things but one of the things it does is it sets up <code>c</code> to be
|
||
valid for the call to <code>Z()</code>. <code>c</code> is <code>argc</code> in <code>main()</code>. As above, <code>Z()</code> is
|
||
called like:</p>
|
||
<pre><code> Z(&(struct a){ .v = { t, I } ,.k=0, .l=c, .h=a, .j=f} );</code></pre>
|
||
<p>That’s fairly simple but <code>Z()</code> itself is nasty. This is what it looks like:</p>
|
||
<pre><code>
|
||
char *Z(struct a *a)
|
||
{
|
||
while (a->h[a->l++])
|
||
(((*a->h[--a->l] == 'e' - ':') && (*a->v)(&(struct a){ .v[0]=I, .j=a->k,.s=((a->l)[a->h])+1 } )
|
||
&&++a->l&rpar;||&lpar;a->v[1]&lpar;&&lpar;struct a&rpar; { .v[2]=Y, .x=&lpar;&lpar;a->l&rpar;[a->h]&rpar;,.z=a->j } &rpar;, ++a->l&rpar;&rpar;;
|
||
return "";
|
||
}</code></pre>
|
||
<p>So in this function <code>a->h</code> is <code>argv</code> from <code>main()</code> and <code>a->l</code> is <code>argc</code> from
|
||
<code>main()</code>. What I am doing with this:</p>
|
||
<pre><code> (a->h[a->l++])(((*a->h[--a->l] == 'e' - ':') && (*a->v)(&(struct a){ .v[0]=I, .j=a->k,.s=((a->l)[a->h])+1 } )
|
||
&&++a->l&rpar;||&lpar;a->v[1]&lpar;&&lpar;struct a&rpar; { .v[2]=Y, .x=&lpar;&lpar;a->l&rpar;[a->h]&rpar;,.z=a->j } &rpar;,++a->l&rpar;&rpar;;</code></pre>
|
||
<p>is quite devious. We all know that the order of evaluation in functions is
|
||
unspecified (or was it implementation defined?) but am I actually doing this?
|
||
In fact I’m not (but see below): I’m circumventing this by using
|
||
short-circuiting rules and the comma operator, ensuring that the order <strong>is</strong>
|
||
specified and also <strong>extremely</strong> hard to parse (the constant updating of argc
|
||
makes it even worse, see next part). The reason for the comma operator on both
|
||
parts of the expression (that is the lhs and rhs of the <code>||</code>) is to ensure that
|
||
the argc (<code>a->l</code>) is incremented no matter what.</p>
|
||
<p>More so, I’m not even sure the order of evaluation matters here as there is only
|
||
one function parameter for all the functions besides <code>main()</code>, and it’s a
|
||
<code>struct a *</code>; but if it does matter I’m circumventing the problem anyway by
|
||
short-circuiting it and using the comma operator, both of which control it to
|
||
the way I need: if the lhs of the lhs fails I still update argc and if the lhs
|
||
fails itself the rhs is done but if the lhs of the rhs fails the argc is still
|
||
incremented for the nest iteration in the loop! How is that done?</p>
|
||
<p>Well on the lhs if the first char of the current arg is a <code>-</code> it will call the
|
||
appropriate function (<code>t()</code>), which because it will never return NULL the argc
|
||
will be updated; but if it fails, which means the first char of the current arg
|
||
is NOT a <code>-</code> then the function <code>I()</code> will be called, and this too will never
|
||
return NULL. But in that case I use the comma operator instead of <code>&&</code> to update
|
||
argc.</p>
|
||
<p>The use of the highly nested <code>()</code>s and the anonymous structs and the
|
||
short-circuited logic along with the comma operator makes it really hard to
|
||
follow but it also controls everything in precisely the way I need it.</p>
|
||
<p>Oh but there’s even more in that code…</p>
|
||
<p>Did you notice that in the call to <code>Z()</code> it sets the anonymous struct <code>j</code> to <code>f</code>
|
||
and <code>k</code> (all of which are a <code>struct a *</code>) to 0? Now what happens in <code>Z()</code>. First
|
||
this part:</p>
|
||
<pre><code> (*a->v)(&(struct a){ .v[0]=I, .j=a->k,.s=((a->l)[a->h])+1 } )</code></pre>
|
||
<p>calls a function (I’m trying to finish this up and I added this late so I am not
|
||
even sure which one exactly even if I said it above or have it in the commented
|
||
code) and in <strong>THAT</strong> function the <code>struct a *</code> (again anonymous) has the <code>j</code>
|
||
pointer (a <code>struct a *j</code>) to <code>a->k</code> which was set to 0 in the call to <strong>THIS</strong>
|
||
function. This might be called a red herring though because right after that you
|
||
have:</p>
|
||
<pre><code> &lpar;a->v[1]&lpar;&&lpar;struct a&rpar; { .v[2]=Y, .x=&lpar;&lpar;a->l&rpar;[a->h]&rpar;,.z=a->j } &rpar;</code></pre>
|
||
<p>which sets in <strong>THAT</strong> function <code>z</code> to <code>a->j</code>. With the formatting above it’s
|
||
bad enough but in prog.c it’s even worse. Now then the function that this calls
|
||
is <code>I()</code> (I think the other one might be <code>Y()</code> but I’m not sure - in any case it
|
||
doesn’t matter as the pointer is not needed there or if it is it’s not used by
|
||
that name) and that does:</p>
|
||
<pre><code> ... for (a
|
||
->a
|
||
= a->z,
|
||
z =
|
||
0*
|
||
*""
|
||
"1"; a
|
||
-> a; a ->
|
||
|
||
a = a->a->e) {
|
||
...</code></pre>
|
||
<p>which means that in <code>I()</code> the pointer <code>a->a</code> is set to <code>f</code>.</p>
|
||
<h3 id="format-of-code">Format of code</h3>
|
||
<p>It’s kind of crazy too though not as crazy as the code itself. Besides the
|
||
spaces (to point out that spaces in the code are both important and not
|
||
important - or important in the output but not necessarily in the code - or is
|
||
it perhaps vice versa? Neither? Both?) there are some fun shapes and things
|
||
spelt out.</p>
|
||
<p>There is an arrow in the code.</p>
|
||
<p>There is an I in the code. Well okay it’s actually <code>IOCCC</code>. Actually that’s
|
||
still not accurate! It’s <code>IOCCC CCCOI</code> (I think - that’s what I aimed for)!</p>
|
||
<p>If you use your imagination you can kind of see a Christmas tree (though that
|
||
was quite by accident) (I suppose the arrow could also be seen as a Christmas
|
||
tree if modified a bit or you imagine a thin trunk). Another fun thing to point
|
||
out:</p>
|
||
<pre><code> * *
|
||
|
||
"9"-15u/</code></pre>
|
||
<p>kind of looks like a face (perhaps a hooded face?).</p>
|
||
<p>As for prog.alt.c: I thought another approach would be fun. The judges don’t
|
||
like submissions that are just lines merged but since this is just alt code
|
||
(though useful in the submission) and since it took a lot of time and energy to
|
||
format the submission code, I joined the lines mostly and removed all the spaces
|
||
that were possible (I think I managed that). This is an interesting exercise as
|
||
you can see that there are a lot of places that are untraditional (in code) but
|
||
that <strong>must</strong> have spaces. Obviously things like <code>struct a</code> cannot be <code>structa</code>
|
||
but consider the <code>/ *</code>: there are at least 10 of those (I think?) that cannot
|
||
have the space removed because doing so would turn it into a comment! Although
|
||
some of the same expressions are used they are not all the same expression. This
|
||
happens in prog.c though I did not count them (and I have a headache, probably
|
||
from the code, so maybe I miscounted). Another place a space is required (also
|
||
in prog.c):</p>
|
||
<pre><code> s=z+-*"1"-*"1"- -97,L=putchar(!s&&isupper(a->x[0**"z"])?a->a->c[s]:tolower(a->a->c[s]))</code></pre>
|
||
<p>and the reasons are obvious! I am not sure now if there are other places though.</p>
|
||
<h3 id="compiling-and-warnings">Compiling and warnings</h3>
|
||
<p>If <code>DICT</code> is not defined it is defined as <code>"dict"</code> so it’s not really necessary
|
||
if running the program from the same directory - as long as the file exists of
|
||
course.</p>
|
||
<p>When I tested this with <code>clang -Weverything</code> in macOS (no guarantees the judges
|
||
will experience precisely this - and in fact this might have been with macOS 14,
|
||
not 15, although it works fine with 15.5 and presumably in between those
|
||
versions and possibly - and I’d guess likely - earlier) <strong>NO FEWER THAN THREE
|
||
COMPILER WARNINGS ARE WRONG</strong> (actually a fair few more depending on how you
|
||
count them) and if these were ‘fixed’, it would <strong>BREAK THE CODE</strong>, potentially
|
||
if not outright (in fact some absolutely would)!</p>
|
||
<p>One even would be removing the <code>,</code> for a function call (well, not really a
|
||
function but the side-effect is <strong>NEEDED</strong>). That’s the ridiculous <code>-Wcomma</code> one;
|
||
it’s also triggered elsewhere but the side-effects are also being used there and
|
||
as you saw in the Obfuscation section one place this is used to circumvent the
|
||
order of expressions in function calls being unspecified (though that might not
|
||
even be necessary - not sure now).</p>
|
||
<p>Some warnings also appear with <code>gcc</code> instead though and some might appear with
|
||
both; it’s hard to keep track but here is a list of warnings I have disabled.
|
||
The warnings were before I formatted the code and I added obfuscation in at
|
||
least one. I’ll note that below.</p>
|
||
<p>Note that this was before formatting and maybe I did change some code although I
|
||
doubt it.</p>
|
||
<p>This is warning is <strong>WRONG</strong>:</p>
|
||
<pre><code> prog.c:32:22: warning: possible misuse of comma operator here [-Wcomma]
|
||
32 | s=z+-*"1"-*"1"- -97,L=putchar(!s&&isupper(a->x[0**"z"])?a->a->c[s]:tolower(a->a->c[s]));
|
||
| ^
|
||
prog.c:32:3: note: cast expression to void to silence warning
|
||
32 | s=z+-*"1"-*"1"- -97,L=putchar(!s&&isupper(a->x[0**"z"])?a->a->c[s]:tolower(a->a->c[s]));
|
||
| ^~~~~~~~~~~~~~~~~~~
|
||
| (void)( )</code></pre>
|
||
<p>and <code>-Wcomma</code> is one of the most ridiculous warnings of many other ridiculous
|
||
warnings. It would appear that adding that cast might silence the warning but
|
||
it’s not the only one and it’s totally bogus anyway.</p>
|
||
<p>This is <strong>ALSO WRONG</strong>:</p>
|
||
<pre><code> prog.c:48:38: warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
|
||
48 | for (k = (s*2)**"9"-171+*"9"; H=B[J][X?*"1"-49:s/ *"1"+s/ *"1"+1/ *"1"+(s*s*s)][k]; ++k)
|
||
| ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
prog.c:48:38: note: place parentheses around the assignment to silence this warning
|
||
48 | for (k = (s*2)**"9"-171+*"9"; H=B[J][X?*"1"-49:s/ *"1"+s/ *"1"+1/ *"1"+(s*s*s)][k]; ++k)
|
||
| ^
|
||
| ( )
|
||
prog.c:48:38: note: use '==' to turn this assignment into an equality comparison
|
||
48 | for (k = (s*2)**"9"-171+*"9"; H=B[J][X?*"1"-49:s/ *"1"+s/ *"1"+1/ *"1"+(s*s*s)][k]; ++k)
|
||
| ^
|
||
| ==</code></pre>
|
||
<p>and ‘fixing’ it (especially the last part) would <strong>BREAK THE CODE</strong>! It’s
|
||
assignment <strong>AND</strong> (implicit) comparison, not just a comparison, and the
|
||
parentheses are pointless. The assumption it is meant to be an equality test is
|
||
also absurd.</p>
|
||
<p>This warning is <strong>ALSO WRONG</strong>:</p>
|
||
<pre><code> prog.c:137:44: warning: bitwise negation of a boolean expression; did you mean logical negation? [-Wbool-operation]
|
||
137 | F((c=((~~!!~!9u|2**"9"-15u/ *"0"-2u)<<~~!~!~9u),c&=9u,&(struct a){ .l=1, .s=a[c],.v= { &w, &w } } ));
|
||
| ^~~~~~~
|
||
| !
|
||
prog.c:137:46: warning: bitwise negation of a boolean expression; did you mean logical negation? [-Wbool-operation]
|
||
137 | F((c=((~~!!~!9u|2**"9"-15u/ *"0"-2u)<<~~!~!~9u),c&=9u,&(struct a){ .l=1, .s=a[c],.v= { &w, &w } } ));
|
||
| ^~~~~
|
||
| !
|
||
prog.c:137:13: warning: bitwise negation of a boolean expression; did you mean logical negation? [-Wbool-operation]
|
||
137 | F((c=((~~!!~!9u|2**"9"-15u/ *"0"-2u)<<~~!~!~9u),c&=9u,&(struct a){ .l=1, .s=a[c],.v= { &w, &w } } ));
|
||
| ^~~~~~~
|
||
| !
|
||
prog.c:137:16: warning: bitwise negation of a boolean expression; did you mean logical negation? [-Wbool-operation]
|
||
137 | F((c=((~~!!~!9u|2**"9"-15u/ *"0"-2u)<<~~!~!~9u),c&=9u,&(struct a){ .l=1, .s=a[c],.v= { &w, &w } } ));
|
||
| ^~~~
|
||
| !</code></pre>
|
||
<p>and ‘fixing’ it <strong>WOULD BREAK THE CODE</strong>! No I did not mean logical negation and
|
||
the assumption here is ridiculous as well.</p>
|
||
<p>Additionally, this warning is <strong>ALSO WRONG</strong>:</p>
|
||
<pre><code> prog.c:137:52: warning: possible misuse of comma operator here [-Wcomma]
|
||
137 | F((c=((~~!!~!9u|2**"9"-15u/ *"0"-2u)<<~~!~!~9u),c&=9u,&(struct a){ .l=1, .s=a[c],.v= { &w, &w } } ));
|
||
| ^
|
||
prog.c:137:8: note: cast expression to void to silence warning
|
||
137 | F((c=((~~!!~!9u|2**"9"-15u/ *"0"-2u)<<~~!~!~9u),c&=9u,&(struct a){ .l=1, .s=a[c],.v= { &w, &w } } ));
|
||
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
| (void)( )
|
||
prog.c:137:58: warning: possible misuse of comma operator here [-Wcomma]
|
||
137 | F((c=((~~!!~!9u|2**"9"-15u/ *"0"-2u)<<~~!~!~9u),c&=9u,&(struct a){ .l=1, .s=a[c],.v= { &w, &w } } ));
|
||
| ^
|
||
prog.c:137:53: note: cast expression to void to silence warning
|
||
137 | F((c=((~~!!~!9u|2**"9"-15u/ *"0"-2u)<<~~!~!~9u),c&=9u,&(struct a){ .l=1, .s=a[c],.v= { &w, &w } } ));
|
||
| ^~~~~
|
||
| (void)( )</code></pre>
|
||
<p>Removing the comma would <strong>BREAK THE CODE</strong>. In particular, the side-effect of
|
||
it is needed (see next one too). Casting to void is totally unnecessary, though
|
||
it will at least compile without warnings, if done the way they want (did not
|
||
test the outcome but I know in some cases this ‘fix’ can break code as well so
|
||
I’m not going to risk that with code that’s already highly obfuscated). Besides,
|
||
as you can see, there are other reasons to disable the warning, all because it’s
|
||
wrong.</p>
|
||
<p>Also, as for another place where <code>-Wcomma</code> is triggered:</p>
|
||
<pre><code> prog.c:67:68: warning: possible misuse of comma operator here [-Wcomma]
|
||
67 | &&++a->l&rpar;||&lpar;a->v[1]&lpar;&&lpar;struct a&rpar;{ .v[2]=Y,.x=&lpar;&lpar;a->l&rpar;[a->h]&rpar;} &rpar;,++a->l&rpar;&rpar;; if &lpar;g&rpar; puts&lpar;""&rpar;; }
|
||
| ^
|
||
prog.c:67:19: note: cast expression to void to silence warning
|
||
67 | &&++a->l&rpar;||&lpar;a->v[1]&lpar;&&lpar;struct a&rpar;{ .v[2]=Y,.x=&lpar;&lpar;a->l&rpar;[a->h]&rpar;} &rpar;,++a->l&rpar;&rpar;; if &lpar;g&rpar; puts&lpar;""&rpar;; }
|
||
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
| (void)(</code></pre>
|
||
<p>The side effect is <strong>REQUIRED</strong> and casting to void is utterly pointless
|
||
(unknown if it is harmful). Actually as I said before, as this is function
|
||
<code>Z()</code>, something extremely nasty is being done here, which is detailed better
|
||
(if not to complete satisfaction) <a href="deobfus.c">deobfus.c</a> and the Obfuscation
|
||
section earlier in this file. And this one is one that changed at the end, where
|
||
it has the new pointer assignment of the <code>struct a *</code> in <code>struct a</code>. I am trying
|
||
to finish up writing my remarks as the contest is not running for much longer.</p>
|
||
<p>Besides that, as it’s so complicated I would risk breaking something by trying
|
||
to squelch the warning. In fact at one point I tried to break it down into
|
||
smaller chunks and I failed. I could not do it. It abuses the comma operator but
|
||
it is not a misuse of the comma operator.</p>
|
||
<p>Personally I believe that this warning is an antitheses to C and although I
|
||
might be wrong I do believe that anything other than in a for loop (or similar
|
||
say <code>int a, b, c;</code>) triggers this warning but the question is is that even
|
||
considered the comma operator in those cases (don’t believe so in the latter but
|
||
unsure on the former)?</p>
|
||
<p>The gcc warnings (plural):</p>
|
||
<pre><code> prog.c: In function 'I':
|
||
prog.c:48:51: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
|
||
48 | for (k = (s*2)**"9"-171+*"9"; H=B[J][X?*"1"-49:s/ *"1"+s/ *"1"+1/ *"1"+(s*s*s)][k]; ++k)
|
||
| ^
|
||
prog.c: In function 'Z':
|
||
prog.c:67:16: warning: value computed is not used [-Wunused-value]
|
||
67 | &&++a->l&rpar;||&lpar;a->v[1]&lpar;&&lpar;struct a&rpar;{ .v[2]=Y,.x=&lpar;&lpar;a->l&rpar;[a->h]&rpar;} &rpar;,++a->l&rpar;&rpar;; if &lpar;g&rpar; puts&lpar;""&rpar;; }
|
||
| ^~
|
||
prog.c: In function 'main':
|
||
prog.c:137:37: warning: suggest parentheses around arithmetic in operand of '|' [-Wparentheses]
|
||
137 | F((c=((~~!!~!9u|2**"9"-15u/ *"0"-2u)<<~~!~!~9u),c&=9u,&(struct a){ .l=1, .s=a[c],.v= { &w, &w } } ));
|
||
| ~~~~~~~~~~~~~~~~^~~
|
||
</code></pre>
|
||
<p>are <strong>ALSO</strong> wrong and the value <strong>IS</strong> used in <code>Z()</code>! Additionally the
|
||
parentheses not there NEED TO NOT BE THERE! The function <code>Z()</code>, again, was
|
||
updated for even more obfuscation and that is not reflected in the above
|
||
warning, like the earlier one.</p>
|
||
<p>The warning <code>-Wmissing-prototypes</code> is stupid because the functions are defined
|
||
before use, obviously. The warning <code>-Wmissing-variable-declarations</code> is equally
|
||
as stupid for the same reason. What clang is saying is it wants <code>static</code> or
|
||
<code>extern</code> some declaration elsewhere (like a header file which is not allowed and
|
||
is pointless anyway).</p>
|
||
<p>The misleading indentation warning (if it is triggered) is nonsense and so
|
||
frequently has to be disabled by many contestants for the contest; whether after
|
||
formatting it is still a problem or not I do not know as I disabled it earlier
|
||
on. It is style policing and should NEVER have been added to gcc. Unfortunately
|
||
clang followed suit.</p>
|
||
<p>These are primarily triggered by <code>clang -Weverything</code> but some are triggered by
|
||
<code>gcc -Wextra</code> (I think it’s <code>-Wextra</code> and not <code>-Wall</code>).</p>
|
||
<p>The empty while loop warning is asinine. There is no need for a body and it’s a
|
||
standard C idiom. The notion the <code>;</code> should be on a separate line is format
|
||
style policing but if they deem it ‘confusing’ I guess that’s a good thing!</p>
|
||
<h4 id="a-special-warning-worth-mentioning-is--wusing-c">A special warning worth mentioning is <code>-Wusing-C</code></h4>
|
||
<p>Okay obviously that’s not what it’s really called but it should be: in some
|
||
systems the warning <code>-Wunsafe-buffer-usage</code> is triggered in <strong>MANY</strong> places.
|
||
This is because one is using pointers as a buffer or to access a buffer or some
|
||
such but it’s essentially warning that the program is in C; hence they should
|
||
just rename it <code>-Wusing-C</code> and be done with it because that’s basically what
|
||
they’re warning against!</p>
|
||
<p>The fact you can’t even safely iterate through <code>argv</code> of <code>main()</code> even when
|
||
<code>argv[argc]</code> is required to be NULL should say all you need to know about it
|
||
being a TERRIBLE idea. Just like a lot of warnings in clang. Okay and gcc too…</p>
|
||
<p>Of course changing the code to not use pointers like I do would <strong>ALSO BREAK THE
|
||
CODE</strong> (if it’s even possible - which of course it’s not, especially seeing it
|
||
requires argc/argv)!</p>
|
||
<p>On this system, with <code>clang -Weverything</code>, a total of <strong>81</strong> (!!) warnings were
|
||
issued and <strong>NOT A SINGLE ONE</strong> was valid (and perhaps it’s more now after last
|
||
minute changes - not sure)!</p>
|
||
<h4 id="warning-summary">Warning summary</h4>
|
||
<p>Basically the warnings that are triggered are either plain wrong or useless and
|
||
with several (quite a few) if I were to ‘fix’ them it would break the code. It
|
||
<strong>MIGHT</strong> be possible to ‘fix’ some of them but this is FAR from clear and it’s
|
||
unnecessary as well.</p>
|
||
<p><strong>IF</strong> any could be ‘fixed’ without sacrificing obfuscation AND not break the
|
||
program due to not it being so twisted (which is quite unlikely) I would guess
|
||
it’s the ridiculous cast to void one. But that can cause bugs as well. As I
|
||
said, and as you probably saw, the comma operator is used extensively and trying
|
||
to placate that ridiculous comma warning would be a nightmare even with casting
|
||
to void. It’d be impossible to change the code without deobfuscating it - and
|
||
likely it would break as well.</p>
|
||
<p>Even so it’s clear that a lot of abuse of the language is in this program, some
|
||
of which makes it quite hard to follow. As I said for <code>Z()</code> (how fun that that
|
||
rhymes) its loop is deranged and when I tried to numerous times break it up for
|
||
some issue I could not do it without causing numerous errors in the code, and I
|
||
am not referring to syntax errors.</p>
|
||
<p>Plus the set up in <code>main()</code> for that (and other) functions is something else.
|
||
The anonymous structs in each function call with different meanings of the
|
||
members of the struct is really nasty to follow as you can never know what is
|
||
really going to be called or what is what in general, exactly as it should be in
|
||
<del>production</del> obfuscated code!</p>
|
||
<div id="how">
|
||
<h3 id="how-is-the-dictionary-file-encrypted">How is the dictionary file ‘encrypted’?</h3>
|
||
</div>
|
||
<p>Well it’s just that <code>Z</code> is <code>A</code>, <code>Y</code> is <code>B</code> etc. If you need to undo the
|
||
substitution try:</p>
|
||
<pre><code> tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'ZYXWVUTSRQPONMLKJIHGFEDCBA' < dict</code></pre>
|
||
<p>Beware that the language did have quite racist terms for certain countries; I
|
||
will not point them out but did want to warn. This won’t matter for the
|
||
translator however as those are the literal translations of the words used for
|
||
other things - so you won’t see those words unless you look at the file.</p>
|
||
<p>I might also add that to have the file translated back to the original format
|
||
would remove obfuscation - if I could even fix the code to work in the first
|
||
place. That is not the only reason I did it but it is a reason it is staying
|
||
that way.</p>
|
||
<p>If you wish to know what the words actually are, I gave a link earlier on, which
|
||
might (haven’t checked it in ages) have more context as well. So I would
|
||
recommend you check that instead. Still now you know what I did if you wish to
|
||
try and figure out how the obfuscation works. I guess the function that does
|
||
this transliteration is <code>w()</code> and of course that also uses the anonymous struct
|
||
so you’d have to trace the call to that.</p>
|
||
<p>Of course, as <code>w</code> is also a member in the struct that does not help (can’t
|
||
search for <code>w</code> on a word boundary without encountering the members too, members
|
||
that mean different things at different times). If you must know, and I’m not
|
||
guaranteeing this (the heavily commented file might be better at this - you’ll
|
||
have to check as this edit is on the last full day of the contest!) it would
|
||
appear to be <code>v[0]</code> and <code>v[1]</code> and called in some function from <code>main()</code>. No
|
||
that’s not a typo of <code>main()</code>. Both 0 and 1 seem to point to <code>w()</code>.</p>
|
||
<div id="sam">
|
||
<h3 id="unsinkable-sam-medical-records---funny-card">Unsinkable Sam Medical Records - funny card</h3>
|
||
</div>
|
||
<p><img src="sam.jpg"
|
||
alt="medical records card of fabled Unsinkable Sam of Second World War"
|
||
width=640 height=640></p>
|
||
<div id="spaces">
|
||
<h3 id="the-issue-of-spaces">The issue of spaces</h3>
|
||
</div>
|
||
<p>Here I will talk about the more technical details on why the spaces have to be
|
||
there as well as things I tried to get it to work, keeping in mind the
|
||
constraints of the size limits that I was under (while maintaining the
|
||
obfuscation - if I could even unwind it). I also talk about spaces in general:
|
||
oddities that might be noticed at times.</p>
|
||
<p>Anyway, to have the reverse with just a few mods is just a bonus, and to have
|
||
the reverse is a bonus in general. It is not clear to me how else it could be
|
||
done.</p>
|
||
<p>The real trouble is how the language worked. If there was not a word in their
|
||
dictionary they would take the letters of those words and just spell it out with
|
||
their words for the letters. But of course this included multiple words so there
|
||
is the identification issue: what word is actually meant? What if the user means
|
||
something else (which as shown elsewhere this already is a feature of the
|
||
language!).</p>
|
||
<p>But with translations being multiple words, how would it work without spaces
|
||
(which are mostly an invention for written text, something they only did after
|
||
translating it in their head)? This system does not allow a reverse simply by
|
||
passing the ciphertext back into it. If it did have that it would be far weaker
|
||
(and remember that’s not even the only layer) and would have been much more
|
||
prone to being compromised.</p>
|
||
<p>In order to make it as natural as possible for input, spaces have to be used,
|
||
and as said, the translation back is just a bonus - not even strictly needed but
|
||
I wanted to be complete.</p>
|
||
<p>Another question is how to translate it back to English when the word might not
|
||
be in the dictionary? Consider this word: <code>foo</code>. If we print the translation
|
||
without spaces we will get:</p>
|
||
<pre><code> chuoa-khaa-kha</code></pre>
|
||
<p>and with spaces:</p>
|
||
<pre><code> chuo a-kha a-kha</code></pre>
|
||
<p>Consider the first one. If we’re searching for exact matches (ignoring
|
||
<code>!isalpha()</code>) how can the first translate back to <code>foo</code>? It can’t because
|
||
<code>chuoa-khaa-kha</code> is not any word (that is, the ‘word’ does not even indicate a
|
||
letter to spell out the word)! There is no space there. That is the problem
|
||
at the core.</p>
|
||
<p>Now as for what might be done with it. There are a number of things that can be
|
||
considered and I have tried all of these - and others. Unfortunately they do not
|
||
work and I believe would be a disservice to the language as well.</p>
|
||
<p>Why would it be a disservice? Because it would not be a genuine translator.
|
||
There would be no point in it.</p>
|
||
<p>Anyway here are some things I did try (amongst others not listed) (keep in mind
|
||
I also had already heavily obfuscated things when I tried some of these, but I
|
||
don’t think that even matters - and it was not as obfuscated as it is now, btw):</p>
|
||
<ul>
|
||
<li>We could just ignore the problem; after all they did. In fact the Americans
|
||
did not even know it - hence the story I mentioned earlier on in the
|
||
introduction of this. That’s what I’m doing and of course this is what does
|
||
work.</li>
|
||
<li>We can try with the shell adding <code>"</code> or <code>'</code> and then having spaces we can
|
||
tokenise it with <code>strtok()</code>. This almost worked but it had problems with some
|
||
translations for the same reason as noted above. In some cases without the
|
||
tokenisation in <code>I()</code> it does work but not in all. But tokenisation is
|
||
problematic anyway.</li>
|
||
<li>other things as well, some mentioned below.</li>
|
||
</ul>
|
||
<p>Now, what can be done about this lack of spaces (in some cases and in other cases
|
||
extra spaces, though as discussed this does not always happen - see further down
|
||
for more details on this and why it’s actually a feature and one worth having)?</p>
|
||
<p>One thought - which I tried - is that I tokenise it by spaces and then add a
|
||
space for each ‘word’ translated. But still what to do about the fact that a
|
||
word is no longer there if the letters are merged?</p>
|
||
<p>Well in the case of words in the dictionary it is not an issue. But the words
|
||
that were spelt out - those are an issue.</p>
|
||
<p>Another thing I tried, and this was the closest thing to working (but it did not
|
||
work in full), is to check by length. That would be updating the <code>Y()</code> function.</p>
|
||
<p>It would have to skip <code>!isalpha()</code> prior to entering the loop and then it would
|
||
in the inner loop (the one with a ‘break’ if the condition is met) check that
|
||
the length is not beyond the word.</p>
|
||
<p>The theory there is that if the letters match (other characters ignored) and the
|
||
length (number of times we iterated not counting the ignored characters) is the
|
||
length of the encoded string we would then ‘break out’ and so as long as the
|
||
string is empty or the length is the same it would be a match.</p>
|
||
<p>This did not work so well either although I did confirm that the <code>Y()</code> loop
|
||
broke out in what appeared to be the right place. One thing is that the code in
|
||
<code>Z()</code> would have to be updated in ways that caused other issues and so this was
|
||
obviously the wrong choice too.</p>
|
||
<p>Keep in mind this too: the matching routine does do some nice things to make it
|
||
a bit easier for input, some of which I already mentioned (I think). Having
|
||
extra spaces is not a big deal. We might even say it is kind of like how the
|
||
Code Talkers had to take a brief moment in translation - and under high stakes.</p>
|
||
<p>There were other problems as well though. If I got one case fixed another was
|
||
then broken. Worse was that the way it has to be tokenised (it is the only way
|
||
if we want to translate back, which again is just a nice bonus, and not
|
||
something they even had to do!) it means the shell has to help out sometimes (I
|
||
showed an example earlier I think). In one case I got what seemed to work (but
|
||
not completely). But this:</p>
|
||
<pre><code> ./prog.alt $(./prog foo) # where foo is the correct format</code></pre>
|
||
<p>did not work (but it should now); instead I had to do something like:</p>
|
||
<pre><code> OUT=$(./prog ...)
|
||
./prog.alt $OUT # or maybe it was "$OUT", not sure now</code></pre>
|
||
<p>This is not useful and very unwieldy, to say nothing about it being error prone
|
||
and problematic in other ways. That might still be useful in cases where I noted
|
||
oddities but I’m not sure of that. Fortunately the above example is not needed
|
||
now.</p>
|
||
<p>As it is spaces abound!</p>
|
||
<p>So given these facts and given the amount of frustration I had, and a large part
|
||
of that is because the code is so ridiculously twisted (as you certainly have
|
||
seen and appreciate by now), as well as how the system worked, I decided to
|
||
recall to you the fact that the Code Talkers did this all in their head, they
|
||
knew the language, and they had the convenience of not having to come up with
|
||
word boundaries. They did not need spaces but it didn’t hurt if they had them.</p>
|
||
<p>Some space issues were resolved, an example above. Another one is that it used
|
||
to on the second line (and those beyond the second line) when reading in from a
|
||
file print a space at the beginning of the line. This was solved with the code
|
||
that uses the <code>L</code> int.</p>
|
||
<p>As I noted elsewhere (I think) other cipher systems are not problematic in this
|
||
case; for instance with the Enigma they transmitted it over Morse and they had
|
||
spaces. I don’t recall how this was transmitted but it was markedly different in
|
||
how it worked; whereas in the Enigma (and many other ciphers, though I believe
|
||
the Culper Code is one of the exceptions) you aren’t limited to specific words,
|
||
with this you are, and you have to spell out the words by the words for its
|
||
letters (the Culper Code might also be this but I’m not sure).</p>
|
||
<p>Going back to the disservice part: I believe it would be an <strong>injustice to the
|
||
language</strong> if this was resolved, if it even can be done without reaching the
|
||
IOCCC size limits (I was able to several times get it down but more problems
|
||
showed up which required more code, and I never did solve it to a satisfactory
|
||
level, based on what I just explained and you now hopefully understand and
|
||
appreciate), because the spaces are a testament to its obscurity (even though
|
||
those over radio do not need spaces), though as you noticed I did get some of it
|
||
resolved.</p>
|
||
<p>Oh and yes: the size is not at 2503 now. But trying to resolve these ‘issues’
|
||
brought it there and beyond.</p>
|
||
<p>I do not actually believe it is possible to get rid of the spaces where they are
|
||
and might be deemed incorrect, especially if there is to be a way to translate
|
||
back to English which seems like a good idea (although I did say it might be a
|
||
disservice here, obviously they had to do it, but they didn’t have to worry
|
||
about spaces or word boundaries); this is just the way it is given the multiple
|
||
ways a word can be translated (dictionary translation or else spelt out with
|
||
multiple words, the real trouble).</p>
|
||
<p>The file mode could have been removed to help with bytes but this limits input
|
||
even more though perhaps given the potential traps it is not really worth it.
|
||
Maybe I should spend time doing something else but given the issues and given
|
||
the amount of obscurity in the code, it would seem to me that it fits the Navajo
|
||
Code Talking language quite well.</p>
|
||
<p>The fact they did this in their heads in mere minutes, they really were coding
|
||
machines (or maybe encoding and decoding machines) and they had no room for
|
||
error; the fact trying to remove spaces introduces errors and input problems is
|
||
another reason to not worry about spaces, especially as they did not worry about
|
||
it either as they had no need to break it up, not needing word boundaries in the
|
||
way I do! Nobody speaks like this (and I hope this doesn’t change):</p>
|
||
<blockquote>
|
||
<p>Bang. Space. Bang. Space. Maxwell’s. Space. Silver. Space. Hammer …</p>
|
||
</blockquote>
|
||
<p>That would be ridiculous. We don’t need spaces when speaking. We don’t need to
|
||
see or not see spaces as one is speaking as we’re listening, not reading (okay,
|
||
fine, maybe there are a few very rare exceptions but in general not).</p>
|
||
<p>Even so I believe the only spaces left are those that are required and in some
|
||
if not all cases they (those) are mere technicalities.</p>
|
||
<p>Basically, and this is important if you wish to be critical of the spaces:
|
||
spaces are not meant for speaking and that is what they did. They had no visual.
|
||
It was all in their head and they translated it in a matter of minutes. They DID
|
||
write it down for their comrades but the spaces IN translation were utterly
|
||
irrelevant just as they are irrelevant when you’re speaking.</p>
|
||
<p>I will close this out with these final remarks:</p>
|
||
<p>In particular, the spaces are added to <strong>help out</strong> in <strong>use of the program</strong>.
|
||
This means that sometimes the output can look odd. You’ll notice this especially
|
||
if there is not a word in the dictionary and it has to be spelt one letter at a
|
||
time. This is done so that translations can at least work even if sometimes (for
|
||
instance in <code>./prog.alt $(./prog b c d)</code> the spaces are not as you wish (or do
|
||
not exist - or presumably not as you wish).</p>
|
||
<p>If a file being read, depending on how you use the program, has a character that
|
||
is interpreted by the shell (such as <code>*</code>) then just like any other command that
|
||
could cause problems as the shell will have done its thing before the program
|
||
gets the input.</p>
|
||
<p>Of course to expect one to be able to translate prog.c to Navajo Code Talkers
|
||
and back to English to compile is rather absurd, although you might notice the
|
||
alt code can read in the code and redirect to another file that can then be
|
||
compiled (at least in some cases). It’s important to remember though that the
|
||
alt code simply prints words that are not in Navajo AS IS, UNTOUCHED, and it
|
||
does not print spaces between words - so any spaces are literal. You can observe
|
||
this at the command line too:</p>
|
||
<pre><code> $ ./prog.alt shush moasi
|
||
bc
|
||
|
||
$ ./prog.alt shush ' ' moasi
|
||
b c</code></pre>
|
||
<p>This is a feature and actually can demonstrate the momentary pause as they
|
||
encoded/decoded the message!</p>
|
||
<h3 id="why-i-think-this-entry-is-worthy-of-winning">Why I think this entry is worthy of winning</h3>
|
||
<p>The Code Talkers should be honoured and acknowledged and what better place in a
|
||
contest about obscuring code?</p>
|
||
<p>I’ve shown everyone that you can do arithmetic on strings in C! Even those few
|
||
who might know this fact would have to actually think about what each of these
|
||
evaluates to (maybe there are a few people who wouldn’t but that’s probably
|
||
extremely rare) and then test their theory out each time (even those who might
|
||
not need a moment to evaluate it in their head might have to do this). The odds
|
||
are they’ll have to look at the ASCII table first.</p>
|
||
<p>That some of these are recursive and in ternary operator in a loop makes it
|
||
harder to follow still. For instance:</p>
|
||
<pre><code> for (k = (s*2)**"9"-171+*"9"; H=B[J][X?*"1"-49:s/ *"1"+s/ *"1"+1/ *"1"+(s*s*s)][k]; ++k)</code></pre>
|
||
<p>is not easy to parse but that’s probably a simpler one. A much more ridiculous
|
||
one is:</p>
|
||
<pre><code> for (J = *"1"-*"1"; J < 26 && B[J][X?1/ *"1"+s/
|
||
*"1"+1/ *"1"+s/ *"1"+1+(s-s)**"1"+(s*(s-s))**"1":((((s-1)**"1")**"1")**"1")**"1"]; ++J)</code></pre>
|
||
<p>The array <code>B</code> is not going to be easy to parse for most people and the use of it
|
||
is hard to parse too, given the arithmetic on strings (and other things). I
|
||
thought about making the alphabet itself encrypted but I needed bytes for more
|
||
interesting things; after all what difference does it make if you can translate
|
||
the rather unknown language when the program (or alt code) can do it for you
|
||
anyway?</p>
|
||
<p>The anonymous structs for each function which has different values per call,
|
||
often in confusing or misleading ways, is something I have not seen in the
|
||
IOCCC, certainly not like this. It makes it hard to follow the code.</p>
|
||
<p>Beautifiers (at least some) are not going to help much as they tend to keep
|
||
spaces in place. Of course if the beautifier is not careful it can turn some of
|
||
my code into comments. Some beautifiers are better than others when it comes to
|
||
shortening the program length but I’m not going to help you with that.</p>
|
||
<p>Oh and btw: what is prog.obfus.c? I think that was a file that I at one point
|
||
ran the code on though I might have had to manipulate the output a bit, in order
|
||
to get it to compile. It very likely (based on the timestamp) was an older
|
||
version of the code, perhaps one of the <code>prog.2.c</code> or <code>prog.3.c</code> files. I’m not
|
||
sure now though. What is <code>prog.pre-format.c</code>? That was a copy of what was
|
||
<code>prog.c</code> at 8 March 2023: so you can see how much it has changed since then as
|
||
well. Similar with some of the other code files. The <a href="deobfus.c">deobfus.c</a> is
|
||
as noted a heavily commented file although as you’ll see there is some I cannot
|
||
parse even myself.</p>
|
||
<p>One more thing. The <a href="try.sh">try.sh</a> script has a fun demonstration of
|
||
<code>prog.alt</code> on itself which is then compiled and run on that source file and then
|
||
runs diff on the two files, showing something interesting. I did not have it as
|
||
a try.alt.sh because the try.sh already relies on both being compiled so I
|
||
figured I’d save a file.</p>
|
||
<!--
|
||
|
||
Copyright © 1984-2025 by Landon Curt Noll and Leonid A. Broukhis. All Rights Reserved.
|
||
|
||
You are free to share and adapt this file under the terms of this license:
|
||
|
||
Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)
|
||
|
||
For more information, see:
|
||
|
||
https://creativecommons.org/licenses/by-sa/4.0/
|
||
|
||
-->
|
||
<!-- AFTER: last line of markdown file: 2024/ferguson2/README.md -->
|
||
|
||
<!-- END: this line ends content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||
<!-- START: this line starts content for HTML phase 22 by: bin/output-index-inventory.sh via bin/md2html.sh -->
|
||
|
||
<!-- START: this line starts content generated by: bin/output-index-inventory.sh -->
|
||
|
||
<div id="inventory">
|
||
<h1 id="inventory-for-2024ferguson2">Inventory for 2024/ferguson2</h1>
|
||
</div>
|
||
<h2 id="primary-files">Primary files</h2>
|
||
<ul>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/prog.c">prog.c</a> - entry source code</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/Makefile">Makefile</a> - entry Makefile</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/prog.alt.c">prog.alt.c</a> - alternate source code</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/prog.orig.c">prog.orig.c</a> - original source code</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/deobfus.c">deobfus.c</a> - deobfucated source</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/dict">dict</a> - code talker dictionary</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/sam.jpg">sam.jpg</a> - medical record card for Unsinkable Sam</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/try.sh">try.sh</a> - script to try entry</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/dict.orig">dict.orig</a> - code talker dictionary in original form</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/prog.obfus.c">prog.obfus.c</a> - intermedate code obfuscation</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/prog.pre-format.c">prog.pre-format.c</a> - 2023 Mar 8 version of prog.c</li>
|
||
</ul>
|
||
<h2 id="secondary-files">Secondary files</h2>
|
||
<ul>
|
||
<li><a href="2024_ferguson2.tar.bz2">2024_ferguson2.tar.bz2</a> - download entry tarball</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/README.md">README.md</a> - markdown source for this web page</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/.entry.json">.entry.json</a> - entry summary and manifest in JSON</li>
|
||
<li><a href="https://github.com/ioccc-src/winner/blob/master/2024/ferguson2/.gitignore">.gitignore</a> - list of files that should not be committed under git</li>
|
||
<li><a href=".path">.path</a> - directory path from top level directory</li>
|
||
<li><a href="index.html">index.html</a> - this web page</li>
|
||
</ul>
|
||
<hr style="width:10%;text-align:left;margin-left:0">
|
||
<h4>
|
||
Jump to: <a href="#">top</a>
|
||
</h4>
|
||
|
||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||
|
||
<!-- END: this line ends content for HTML phase 22 by: bin/output-index-inventory.sh via bin/md2html.sh -->
|
||
<!-- START: this line starts content from: inc/after-content.default.html -->
|
||
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/after-content.default.html -->
|
||
<!-- START: this line starts content from: inc/footer.inventory.html -->
|
||
|
||
<!--
|
||
|
||
Copyright © 1984-2025 by Landon Curt Noll. All Rights Reserved.
|
||
|
||
You are free to share and adapt this file under the terms of this license:
|
||
|
||
Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)
|
||
|
||
For more information, see:
|
||
|
||
https://creativecommons.org/licenses/by-sa/4.0/
|
||
|
||
-->
|
||
|
||
<div class="footer">
|
||
|
||
<div id="copyright"><h3>Copyright © 1984-2025 by Landon Curt Noll:
|
||
<a href="https://creativecommons.org/faq/#what-does-some-rights-reserved-mean"
|
||
target="_blank"
|
||
rel="license noopener noreferrer">Some Rights Reserved</a></h3>
|
||
<p>
|
||
This work is <b>licensed by Landon Curt Noll</b> under
|
||
<b><a href="https://creativecommons.org/licenses/by-sa/4.0/?ref=chooser-v1"
|
||
target="_blank"
|
||
rel="license noopener noreferrer"
|
||
style="display:inline-block;">CC BY-SA 4.0</a></b>.
|
||
<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;"
|
||
src="../../png/cc.png"
|
||
alt="cc inside circle symbol">
|
||
<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;"
|
||
src="../../png/by.png"
|
||
alt="person inside circle symbol">
|
||
<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;"
|
||
src="../../png/sa.png"
|
||
alt="arrow looping back on itself inside circle symbol"><br>
|
||
You should <b>carefully review</b> the
|
||
<b><a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode.en"
|
||
target="_blank"
|
||
rel="license noopener noreferrer">CC BY-SA 4.0 LEGAL CODE</a></b>
|
||
before using the licensed material.<br>
|
||
You may wish to review the
|
||
<b><a href="../../license.html"
|
||
target="_blank"
|
||
rel="license noopener noreferrer">highlights of some of the key features and terms</a></b>
|
||
of <b>CC BY-SA 4.0</b>.<br>
|
||
</p>
|
||
</div>
|
||
|
||
<div id="coda"><h3>Coda</h3>
|
||
<p>
|
||
<a href="https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.ioccc.org%2F2024%2Fferguson2%2Findex.html" rel="nofollow">Nu HTML check this web page</a><br>
|
||
<a href="#top">Jump to top</a> <a href="#content">Jump to Content</a> <a href="#inventory">Jump to Inventory</a><br>
|
||
</p>
|
||
</div>
|
||
|
||
</div>
|
||
|
||
<!-- END: this line ends content from: inc/footer.inventory.html -->
|
||
<!-- START: this line starts content from: inc/bottom.default.html -->
|
||
|
||
</body>
|
||
</html>
|
||
|
||
<!-- END: this line ends content from: inc/bottom.default.html -->
|