Files
ioccc/2018/yang
Landon Curt Noll 4ee4c731f7 convert markdown copyright TAB chars into SPACE chars
While not strictly necessary, replacing the two ASCII tab characters
in the markdown copyright comment makes it easier to detect problematic
TAB indentation within markdown files.

After this commit, only 90 markdown files have leading ASCII TAB
characters.  And again, while not strictly necessary, we can consider
running expand on those 90 markdown files to see what effect that
might have on the HTML files they produce.

Replace leading ASCII TAB characters with multiples of 8 ASCII SPACE
characters (the default action of the `expand(1)` tool) might have
an negative effect on some HTML formatting where **hack-a-round**
formatting was attempted to fix broken indentation caused by
problematic ASCII TAB characters.

Think of this as a baseline for evaluating leading
TAB characters within markdown files.

TODO: Consider either using `expand(1)` to replace leading ASCII
TAB characters with multiples of 8 ASCII SPACE characters AND/OR
modifying the appropriate `bin` tool to convert leading ASCII TAB
characters into multiples of 8 ASCII SPACE characters.
2024-06-22 22:15:25 -07:00
..
…
…
…
…

To build:

    make

To use:

The author suggested that after compilation one should look at the generated files. For instance:

    less generated1.c
    less generated2.c
    less generated3.c

Try:

    ./try.sh

Judges' remarks:

Code should be readable in any direction! This tool will help you rotate your code so you don't have to stare at it sideways or even upside down. Rotating this program left and recompiling will reveal other tools including a right rotate and a shift program.

Strange things happen when the world is upside down! It is entirely possible that this remark is completely misleading.

What exactly does the shift program do?

Like a great sliding puzzle (hint) this entry has six more programs that will reveal messages and one more tool that can be used to reveal the final message hidden in the original source. All of these can be created using combinations of ./left, ./right and ./shift and the additionally generated programs.

The final message can be revealed using

    ./msg9 < prog.c

But what combinations will generate ./msg3, ./msg4, ./msg5, ./msg6, ./msg7, ./msg8 and finally ./msg9?

Author's remarks:

Tools' usage:

Nuko is a text rotator: given some text in stdin, Nuko will write the same text to stdout, but rotated 90 degrees counterclockwise.

    cc prog.c -o left
    ./left < input.txt > rotated_counterclockwise.txt

Due to static memory allocation, only the first 1K columns by 1K rows are rotated, the rest are silently ignored. But fear not, a separate tool with dynamic memory allocation is included:

    ./left < prog.c > r1.c
    cc r1.c -o right
    ./right < input.txt > rotated_clockwise.txt

For variety, this second tool rotates clockwise instead of counterclockwise. Also, it can handle files larger than 1024x1024, depending on how much memory you have.

Of course we wouldn't stop with just two rotations, if we continue to rotate counterclockwise once more, we get another program. This program outputs a single message to stdout, which is the name of the series that Nuko came from.

    ./left < prog.c | ./left > r2.c
    cc r2.c -o msg0
    ./msg0

There is one final rotation, which produces a tool that removes leading whitespaces:

    ./left < prog.c | ./left | ./left > r3.c
    cc r3.c -o shift
    ./shift < input.txt > no_leading_space.txt

Where this might be useful, besides ruining the formatting of certain files, is that it completes the set of tools needed to solve the puzzle that is embedded in prog.c.

Puzzle box:

Notice how the edges of prog.c contain two notches. By rotating prog.c and removing leading space, the code would be shifted one space toward one of those notches (and create a new notch on the other side). This shifted code behaves slightly different from the original program. For example, here are two more messages that can be produced:

    ./shift < prog.c | ./right > msg1.c && gcc msg1.c -o msg1 && ./msg1
    ./shift < prog.c | ./left > msg2.c && gcc msg2.c -o msg2 && ./msg2

In total, there are 9 embedded strings that can be produced via a sequence of rotates and shifts, one of which can be used to extract the 10th final string from prog.c. The intent is to simulate those wooden puzzle boxes that can be opened by pushing and shifting various well-concealed seams. Thus, finding the correct sequence of rotates and shifts is left as an exercise to the reader (but if you are really lazy, just read the Makefile.

Source code for all the tools needed to solve this puzzle are embedded in prog.c, all you need is a C compiler.

Features

  • Code compiles when rotated 4 ways. This required a bit of patience to achieve. Code still compiles even with one column of text shifted. This required even more patience.

  • All rotated and shifted variants compile without warnings. This involves various tweaks to satisfy cases where the compiler is overly protective, including but not limited to the "1125" at line 4 as opposed to "1025", to satisfy -Waggresive-loop-optimizations.

  • CRC32 of the code is embedded in the code itself.

  • Process for writing prog.c is available in spoiler.html.

Compatibility:

Nuko and the rotated tools accept only ASCII files where each character maps to exactly one byte. Also, end-of-line sequence is assumed to be LF only, as opposed to CR-LF. All control characters are treated like normal printable characters, so files containing tabs will look weird after rotation, for example.

Nuko has been verified to work with these compiler / OS combinations:

  • gcc 4.8.4 on Linux
  • gcc 4.9.2 on Linux
  • gcc 6.1.0 on JS/Linux
  • gcc 6.3.0 on Linux
  • gcc 6.4.0 on Cygwin
  • clang 3.5.0 on Linux
  • clang 3.8.1 on Linux
  • clang 5.0.1 on Cygwin
  • tcc 0.9.25 on JS/Linux

Nuko compiles without warnings with all compilers above, even with -Wall -Wextra -pedantic for gcc and clang.