Add preview of 1984-2019
The 2020 winners are hinted it, but the source code is not there,
nor are the hints. Someone could look into the HTML and
see what was commented out, but that is not a problem because
WHO won is known and the name of their AWARD is known already.
Moreover a number of the winners have talked about what their
entirs do, so the commented out spoiler text is not a bit problem.
One will find HTML commented out with:
<!-- XXX remove when 2020 is ready
2020 links here
XXX remove when 2020 is ready -->
The "XXX remove when 2020 is ready" string is found at the
start and end comment blocks. Again, soneone could read
what was commented out, but that is OK since most of that
information is known or can be known. The following files
have such HTML comment blocks in them.
./winners.html
./years-spoiler.html
./years.html
In addition, ./all/summary.txt was modified to not
include the 2020 entries for the momemt.
The 2020 winner code AND write-ups are NOT part of this set.
p.s. The all/all.tar.bz2 does not contain the 2020 source code (yet?).
This commit is contained in:
1 parent
28efc67f5d
commit
c0663537cb
1683 files changed
+220064
No files matched your search
@@ -0,0 +1,284 @@
|
||||
#!/usr/bin/env make
|
||||
#
|
||||
# 2018 makefile
|
||||
#
|
||||
# This work by Landon Curt Noll, Simon Cooper, and Leonid A. Broukhis
|
||||
# is licensed under:
|
||||
#
|
||||
# Creative Commons Attribution-ShareAlike 3.0 Unported License.
|
||||
#
|
||||
# See: http://creativecommons.org/licenses/by-sa/3.0/
|
||||
|
||||
|
||||
################
|
||||
# tool locations
|
||||
################
|
||||
#
|
||||
SHELL= /bin/bash
|
||||
CP= cp
|
||||
CPP= cpp
|
||||
GUNZIP= gunzip
|
||||
BUNZIP2= bunzip2
|
||||
GZIP_PROG= gzip
|
||||
BZIP2= bzip2
|
||||
CURL= curl
|
||||
DD= dd
|
||||
LD= ld
|
||||
MAKE= make
|
||||
RM= rm
|
||||
SED= sed
|
||||
TAR= tar
|
||||
TRUE= true
|
||||
MKDIR= mkdir
|
||||
MV= mv
|
||||
TR= tr
|
||||
GREP= grep
|
||||
SORT= sort
|
||||
UNIQ= uniq
|
||||
STRIP= strip
|
||||
|
||||
# Set X11_LIBDIR to the directory where the X11 library resides
|
||||
#
|
||||
#X11_LIBDIR= /usr/X11R6/lib
|
||||
#X11_LIBDIR= /usr/X11/lib
|
||||
X11_LIBDIR= /opt/X11/lib
|
||||
|
||||
# Set X11_INCLUDEDIR to the directory where the X11 include files reside
|
||||
#
|
||||
#X11_INCDIR= /usr/X11R6/include
|
||||
#X11_INCDIR= /usr/X11/include
|
||||
X11_INCDIR= /opt/X11/include
|
||||
|
||||
# Compiler warnings
|
||||
#
|
||||
#CWARN=
|
||||
#CWARN= -Wall
|
||||
#CWARN= -Wall -Wextra
|
||||
CWARN= -Wall -Wextra -pedantic ${CSILENCE}
|
||||
#CWARN= -Wall -Wextra -Weverything
|
||||
#CWARN= -Wall -Wextra -Weverything -pedantic
|
||||
#CWARN= -Wall -Wextra -Weverything -pedantic ${CSILENCE}
|
||||
|
||||
# Silence warnings that ${CWARN} would normally complain about
|
||||
#
|
||||
CSILENCE= -Wno-missing-prototypes
|
||||
#CSILENCE= -Wno-implicit-int
|
||||
|
||||
# compiler standard
|
||||
#
|
||||
#CSTD=
|
||||
#CSTD= -ansi
|
||||
CSTD= -std=c11
|
||||
|
||||
# compiler bit architecture
|
||||
#
|
||||
# Some entries require 32-bitness:
|
||||
# ARCH= -m32
|
||||
#
|
||||
# Some entries require 64-bitness:
|
||||
# ARCH= -m64
|
||||
#
|
||||
# By default we assume nothing:
|
||||
#
|
||||
ARCH=
|
||||
|
||||
# defines that are needed to compile
|
||||
#
|
||||
CDEFINE=
|
||||
#CDEFINE= -DIOCCC=25
|
||||
|
||||
# include files that are needed to compile
|
||||
#
|
||||
CINCLUDE=
|
||||
#CINCLUDE= -include stdlib.h
|
||||
#CINCLUDE= -include stdio.h
|
||||
#CINCLUDE= -include stdlib.h -include stdio.h
|
||||
#CINCLUDE= -I ${X11_INCDIR}
|
||||
|
||||
# optimization
|
||||
#
|
||||
# Most compiles will safely use -O2. Some can use only -O1 or -O.
|
||||
# A few compilers have broken optimizers or this entry make break
|
||||
# under those buggy optimizers and thus you may not want anything.
|
||||
# Reasonable compilers will allow for -O3.
|
||||
#
|
||||
#OPT=
|
||||
#OPT= -O
|
||||
#OPT= -O1
|
||||
#OPT= -O2
|
||||
OPT= -O3
|
||||
|
||||
# default flags for ANSI C compilation
|
||||
#
|
||||
CFLAGS= ${CSTD} ${CWARN} ${ARCH} ${CDEFINE} ${CINCLUDE} ${OPT}
|
||||
|
||||
# Libraries needed to build
|
||||
#
|
||||
LIBS=
|
||||
#LIBS= -L ${X11_LIBDIR}
|
||||
|
||||
# ANSI compiler
|
||||
#
|
||||
# Set CC to the name of your ANSI compiler.
|
||||
#
|
||||
# Some entries seem to need gcc. If you have gcc, set
|
||||
# both CC and MAY_NEED_GCC to gcc.
|
||||
#
|
||||
# If you do not have gcc, set CC to the name of your ANSI compiler, and
|
||||
# set MAY_NEED_GCC to either ${CC} (and hope for the best) or to just :
|
||||
# to disable such programs.
|
||||
#
|
||||
CC= cc
|
||||
#CC=clang
|
||||
MAY_NEED_GCC= gcc
|
||||
|
||||
|
||||
##############################
|
||||
# Special flags for this entry
|
||||
##############################
|
||||
#
|
||||
OBJ= prog.o
|
||||
DATA=
|
||||
TARGET= prog
|
||||
#
|
||||
ALT_OBJ=
|
||||
ALT_TARGET=
|
||||
|
||||
|
||||
#################
|
||||
# build the entry
|
||||
#################
|
||||
#
|
||||
all: ${TARGET} ${DATA}
|
||||
@${TRUE}
|
||||
|
||||
prog: prog.c
|
||||
${CC} ${CFLAGS} $< -o $@ ${LIBS}
|
||||
|
||||
# alternative executable
|
||||
#
|
||||
alt: ${ALT_TARGET}
|
||||
@${TRUE}
|
||||
|
||||
# data files
|
||||
#
|
||||
data: ${DATA}
|
||||
@${TRUE}
|
||||
|
||||
|
||||
###############
|
||||
# utility rules
|
||||
###############
|
||||
#
|
||||
everything: all alt
|
||||
|
||||
clean:
|
||||
${RM} -f ${OBJ} ${ALT_OBJ}
|
||||
|
||||
clobber: clean
|
||||
${RM} -f ${TARGET} ${ALT_TARGET}
|
||||
@-if [ -e sandwich ]; then \
|
||||
${RM} -f sandwich; \
|
||||
echo 'ate sandwich'; \
|
||||
fi
|
||||
|
||||
nuke: clobber
|
||||
@${TRUE}
|
||||
|
||||
dist_clean: nuke
|
||||
@${TRUE}
|
||||
|
||||
install:
|
||||
@echo "Surely you are performing, Dr. May!"
|
||||
@${TRUE}
|
||||
|
||||
# backwards compatibility
|
||||
#
|
||||
build: all
|
||||
@${TRUE}
|
||||
|
||||
|
||||
##################
|
||||
# 133t hacker rulz
|
||||
##################
|
||||
#
|
||||
love:
|
||||
@echo 'not war?'
|
||||
@${TRUE}
|
||||
|
||||
haste:
|
||||
$(MAKE) waste
|
||||
@${TRUE}
|
||||
|
||||
waste:
|
||||
@echo 'haste'
|
||||
@${TRUE}
|
||||
|
||||
make:
|
||||
@echo 'Attend a maker faire'
|
||||
@${TRUE}
|
||||
|
||||
easter_egg:
|
||||
@echo you expected to often mis-understand this $${RANDOM} magic
|
||||
@echo chongo '<was here>' "/\\oo/\\"
|
||||
@echo Eggy
|
||||
|
||||
fabricate fashion form frame manufacture produce: make
|
||||
@${TRUE}
|
||||
|
||||
sandwich:
|
||||
@if [ `id -u` -eq 0 ]; then \
|
||||
echo 'Okay.'; \
|
||||
echo $${RANDOM}`date +%s`$${RANDOM} > $@; \
|
||||
else \
|
||||
echo 'What? Make it yourself.'; \
|
||||
exit 1; \
|
||||
fi
|
||||
|
||||
# Understand the history of the Homebrew Computer Club
|
||||
# as well as the West Coast Computer Faire and
|
||||
# you might be confused different. :-)
|
||||
#
|
||||
supernova: nuke
|
||||
@-if [ -r .code_anal ]; then \
|
||||
${RM} -f .code_anal_v6; \
|
||||
else \
|
||||
echo "planet deniers, like some members of the IAU, are so cute when they try to defend their logic"; \
|
||||
fi
|
||||
@echo A $@ helps ${MAKE} the elements that help form planets
|
||||
@${TRUE}
|
||||
|
||||
deep_magic:
|
||||
@-if [ -r .code_anal ]; then \
|
||||
ccode_analysis --deep_magic 3a3fabb90892eeb2f610ae0f74a35a970060665a063ab702bd686c17c4ae07f6 --FNV1a_hash_256_bit "prog"; \
|
||||
else \
|
||||
echo "Wrong! Do it again!"; \
|
||||
sleep 2; \
|
||||
echo "Wrong! Do it again!"; \
|
||||
sleep 2; \
|
||||
echo "Wrong! Do it again!"; \
|
||||
fi
|
||||
@${TRUE}
|
||||
|
||||
magic: deep_magic
|
||||
@-if [ -r .code_anal ]; then \
|
||||
ccode_analysis --mode 216091 --level 216193 --FNV1a_hash_256_bit "prog"; \
|
||||
else \
|
||||
echo "If you don't eat yer meat, you can't have any pudding!"; \
|
||||
echo "How can you have any pudding if you don't eat yer meat?!"; \
|
||||
fi
|
||||
@${TRUE}
|
||||
|
||||
# The IOCCC resident astronomer states
|
||||
#
|
||||
charon: supernova
|
||||
@echo $@ is a dwarf planet
|
||||
@echo dwarf is a type of planet
|
||||
@echo $@ is a planet
|
||||
|
||||
pluto: supernova
|
||||
${MAKE} charon
|
||||
@echo $@ is a dwarf planet
|
||||
@echo dwarf is a type of planet
|
||||
@echo $@ is a planet
|
||||
@echo get used to having lots of planets because a $< can ${MAKE} a lot of them
|
||||
@@ -0,0 +1,8 @@
|
||||
0 4 8
|
||||
1 0
|
||||
2 1 3
|
||||
3 2
|
||||
4 1
|
||||
5 4 6
|
||||
6 5 2
|
||||
7 3 6 7
|
||||
@@ -0,0 +1,8 @@
|
||||
0 1
|
||||
1 2 4 5
|
||||
2 3 6
|
||||
3 2 7
|
||||
4 0 5
|
||||
5 6 5
|
||||
6 5
|
||||
7 3 6
|
||||
@@ -0,0 +1,8 @@
|
||||
0 4 8
|
||||
1 0
|
||||
2 1 3
|
||||
3 2
|
||||
4 1
|
||||
5 4 6
|
||||
6 5 2
|
||||
7 3 6 7
|
||||
@@ -0,0 +1,235 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="GENERATOR" content="mkd2html 2.1.5a DL=DISCOUNT">
|
||||
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
|
||||
<link rel="stylesheet"
|
||||
type="text/css"
|
||||
href="../hint.css">
|
||||
<title>Most connected</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Most connected</h1>
|
||||
|
||||
<p>Scott Vokes<br>
|
||||
Twitter: @silentbicycle</p>
|
||||
|
||||
<h2>Judges' comments:</h2>
|
||||
|
||||
<h3>To use:</h3>
|
||||
|
||||
<pre><code>make
|
||||
./prog < example-1.txt
|
||||
</code></pre>
|
||||
|
||||
<h3>Try:</h3>
|
||||
|
||||
<pre><code>./prog < example-2.txt
|
||||
./prog < example-tab.txt
|
||||
./prog < ioccc.txt
|
||||
</code></pre>
|
||||
|
||||
<h3>Selected Judges Remarks:</h3>
|
||||
|
||||
<p>What this program does is not witchcraft and there are no spectres, but you
|
||||
might have a meltdown trying to work it all out.</p>
|
||||
|
||||
<p>This entry is designed to mislead in many ways. However, if you find yourself
|
||||
wanting to know the possibilities for navigating a graph, you will get the
|
||||
answer you seek with no hocus pocus.</p>
|
||||
|
||||
<h2>Author’s comments:</h2>
|
||||
|
||||
<h2>Introduction</h2>
|
||||
|
||||
<p>This program reads a directed graph (as lines with integer node IDs),
|
||||
and prints the graph’s nodes in reverse-topologically sorted order,
|
||||
grouped into strongly connected components. Given a set of nodes
|
||||
representing targets and edges representing dependencies between them,
|
||||
it produces a build order with any dependency cycles gathered.</p>
|
||||
|
||||
<p>For example, the following input (provided as <code>example-1.txt</code>):</p>
|
||||
|
||||
<pre><code>0 4 8
|
||||
1 0
|
||||
2 1 3
|
||||
3 2
|
||||
4 1
|
||||
5 4 6
|
||||
6 5 2
|
||||
7 3 6 7
|
||||
</code></pre>
|
||||
|
||||
<p>would be interpreted as:</p>
|
||||
|
||||
<pre><code>0 -> 4, 8
|
||||
1 -> 0
|
||||
2 -> 1, 3
|
||||
3 -> 2
|
||||
4 -> 1
|
||||
5 -> 4, 6
|
||||
6 -> 5, 2
|
||||
7 -> 3, 6, 7
|
||||
</code></pre>
|
||||
|
||||
<p>So, node 0 has edges to / depends on nodes 4 and 8, node 1 depends on
|
||||
node 0, and so on. Then, it groups the graph’s nodes into
|
||||
strongly connected components and prints them in reverse-topologically
|
||||
sorted order:</p>
|
||||
|
||||
<pre><code>0: 8
|
||||
1: 0 1 4
|
||||
2: 2 3
|
||||
3: 5 6
|
||||
4: 7
|
||||
</code></pre>
|
||||
|
||||
<p>It uses Tarjan’s strongly connected components algorithm for the
|
||||
grouping and reverse-topological sorting, along with a bonus hidden
|
||||
implementation of counting sort, which sorts each group.</p>
|
||||
|
||||
<p>For other details about the input format, see “Issues and
|
||||
Limitations”.</p>
|
||||
|
||||
<h2>Building</h2>
|
||||
|
||||
<p>To build:</p>
|
||||
|
||||
<pre><code>${CC} -o prog prog.c -std=c11 -O3 \
|
||||
-Wall -Wextra -pedantic -Wno-missing-prototypes
|
||||
</code></pre>
|
||||
|
||||
<p><code>-Wno-missing-prototypes</code> is necessary because there aren’t any
|
||||
prototypes. (They would put the program well over the size limit.)</p>
|
||||
|
||||
<p>Note: The program can also be built with <code>-std=c99</code> or <code>-std=c89</code>.</p>
|
||||
|
||||
<p>If building with <code>-Weverything</code>, then <code>-Wno-strict-prototypes</code>
|
||||
may also be necessary – the function pointer declarations for
|
||||
<code>_</code> and <code>B</code> may get warnings otherwise, for reasons described
|
||||
under “Obfuscations”.</p>
|
||||
|
||||
<h2>Obfuscations</h2>
|
||||
|
||||
<ul>
|
||||
<li><p>This entry uses functions that have a variable number of arguments,
|
||||
but despite what the rules say, there is no need to be careful about
|
||||
<code>va_list</code> implementation differences. :) . There are several
|
||||
references to a function pointer, <code>_</code>, but it’s called with different
|
||||
numbers of arguments in different places. (In particular, look at
|
||||
<code>spell</code>.) Because the function pointer declaration has an empty list
|
||||
of parameters, the argument count and types are unconstrained. <code>_</code> is
|
||||
set to different functions in several places, but it is always called
|
||||
with appropriate argument(s) for its possible current functions. This
|
||||
is allowed by the standard – The section on F,I,N,D,M,Y,C,L,U,E has
|
||||
further details.</p></li>
|
||||
<li><p>It uses <code>_</code> in three different scopes: as a goto label (function
|
||||
scope), as an enum name, and a <code>_</code> function pointer (which is required
|
||||
to have file scope, since it starts with ‘_’). There are also other
|
||||
<code>_</code>s: it appears in a string, obscured by a headecimal escape sequence
|
||||
(<code>\x5f</code>), and the cauldron is supported by a giant underscore.
|
||||
(Does this program qualify for Best One Liner?)</p></li>
|
||||
<li><p>Most of the variables are not only global, but used for unrelated
|
||||
purposes at different times, so just renaming them while studying the
|
||||
program should make it even more confusing. The few variables local to
|
||||
functions have their names reused for different things in other
|
||||
functions.</p></li>
|
||||
<li><p>There is an enum early on that defines several single-letter
|
||||
identifiers: F,I,N,D,M,Y,C,L,U,E. These are used for array offsets,
|
||||
both individually and in combination. The first several values are
|
||||
also a clue: ISO/IEC 9899:1999 chapter 6.7.5.3 verse 14 describes how
|
||||
function declarators with an empty parameter list behave. (As does
|
||||
3.5.4.3 for ANSI C, which explains the 0x3543 that appears soon
|
||||
after.)</p></li>
|
||||
<li><p>Several parts of the program’s state are stashed in otherwise unused
|
||||
offsets of the node arrays. These locations are accessed in multiple
|
||||
ways, such as using <code>I[p]</code> (where I == 7) as well as <code>p[F+L]</code> (6+1),
|
||||
or <code>b[M-N]</code> (14-5) and <code>U[b]</code> (where U == 9).</p></li>
|
||||
<li><p>The other identifiers are misleading, punny, or both. <code>spectre</code> does
|
||||
not exploit CVE-2017-5753 or CVE-2017-5715, for example – it just fits
|
||||
the witch theme. <code>cast</code> doesn’t cast, <code>hex</code> has nothing to do with
|
||||
hexadecimal, <code>bubble</code> is not bubble sort, there is no undefined
|
||||
behavior in <code>nasal_demons</code>, and <code>main</code> has absolutely nothing to do
|
||||
with a hand.</p></li>
|
||||
<li><p>For well-formed input, how the program determines when to exit is a
|
||||
bit obscure. <code>main</code> ends with a <code>goto</code> leading back to an earlier <code>_</code>
|
||||
label, so it just loops forever, and <code>exit</code> only appears in code paths
|
||||
related to error-handling. It looks like <code>cast</code> calls <code>meltdown</code> with
|
||||
its second argument set to 0, which would call <code>exit</code>, but running in
|
||||
gdb with a breakpoint on <code>cast</code> reveals that it isn’t being called…</p></li>
|
||||
<li><p>Instead of using <code>isdigit()</code>, the program checks the numeric value of
|
||||
each <code>char</code>, and literals that would suggest comparing against e.g. ‘0’
|
||||
are specified in octal in one place, and produced by arithmetic using
|
||||
the enum elsewhere.</p></li>
|
||||
<li><p>Common conventions are subverted: <code>i</code> is not a loop index, <code>argv</code> and
|
||||
<code>argc</code>’s names are swapped.</p></li>
|
||||
<li><p><code>NULL</code> does not appear in the program. Instead, <code>argc[argv]</code> (which is
|
||||
required to be a null pointer) is saved and passed to where its value
|
||||
is needed.</p></li>
|
||||
<li><p>Oh, and the program is squashed into the shape of a bubbling cauldron,
|
||||
on top of a giant underscore, so there’s that.</p></li>
|
||||
</ul>
|
||||
|
||||
|
||||
<h2>Issues and Limitations</h2>
|
||||
|
||||
<ul>
|
||||
<li><p>Despite appearances, it does not handle numbers in hex, or provide
|
||||
a <code>curses(3)</code>-based interface.</p></li>
|
||||
<li><p>The expected input format is zero or more lines of space-separated
|
||||
integers. If other characters appear in the input, it will either
|
||||
reject the input entirely and exit with a non-zero status, or skip
|
||||
number(s) adjacent to the non-digit characters, depending on where the
|
||||
characters appear. Tabs and multiple consecutive spaces are handled
|
||||
correctly, however.</p></li>
|
||||
<li><p>Individual lines of input longer than <code>0x3543 - 1</code> bytes will be
|
||||
split and processed as if they were multiple lines of input, which can
|
||||
produce incorrect results. This magic number’s significance is
|
||||
described earlier.</p></li>
|
||||
<li><p>The algorithm expects its input to represent a fully connected graph.
|
||||
While the output is otherwise topologically sorted, if there are nodes
|
||||
completely unconnected to the rest of the graph (with or without
|
||||
self-cycles), they will be output as soon as they are processed –
|
||||
this means that, when there are disconnected nodes, reordering the
|
||||
input lines can produce different output. Addressing this by adding
|
||||
another pass is would put the program over the size limit.</p></li>
|
||||
<li><p>While the node IDs don’t need to be consecutive or start at 0, the
|
||||
implementation doesn’t have special handling for sparse graphs. If you
|
||||
give it a graph with nodes numbered 0 and 2147483647, it will attempt
|
||||
to allocate sufficient memory (potentially around 32 GB) for the
|
||||
entire range of graph nodes, even if those are the only ones. If
|
||||
memory allocation returns NULL, it will gracefully exit, otherwise it
|
||||
will succeed, eventually, perhaps after a great deal of swapping.</p></li>
|
||||
<li><p>Node IDs >= 2147483648 will cause the program to print an error
|
||||
message and exit with a non-zero status. This shrinks the code that
|
||||
detects overflowing the array size by a bit.</p></li>
|
||||
<li><p>A very large group of nodes in a cycle can cause a stack overflow.
|
||||
This typically takes over 100,000 nodes, and depends on the order the
|
||||
nodes are visited. Addressing this would put the program over the size
|
||||
limit.</p></li>
|
||||
<li><p>The implementation depends on the characters ‘0’, ‘1’, … ‘9’ having
|
||||
the values 48 through 57, rather than using <code>isdigit()</code>. As noted
|
||||
above, this program has nothing to do with a hand.</p></li>
|
||||
</ul>
|
||||
|
||||
|
||||
<hr />
|
||||
|
||||
<!--
|
||||
(c) Copyright 1984-2018, [Leo Broukhis, Simon Cooper, Landon Curt Noll][judges] - All rights reserved
|
||||
This work is licensed under a [Creative Commons Attribution-ShareAlike 3.0 Unported License][cc].
|
||||
|
||||
[judges]: http://www.ioccc.org/judges.html
|
||||
[cc]: http://creativecommons.org/licenses/by-sa/3.0/
|
||||
-->
|
||||
|
||||
<TABLE><TR>
|
||||
<TD><a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-sa/3.0/88x31.png" /></a></TD>
|
||||
<TD><P>© Copyright 1984-2018,
|
||||
<A HREF="/judges.html">Leo Broukhis, Simon Cooper, Landon Curt Noll</A>
|
||||
- All rights reserved<BR>
|
||||
This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-ShareAlike 3.0 Unported License</a>.</P></TD>
|
||||
<TD> <!--<a href="http://validator.w3.org/check?uri=referer"><img src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01 Transitional" height="31" width="88"></a>--></TD>
|
||||
</TR></TABLE>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,224 @@
|
||||
# Most connected
|
||||
|
||||
Scott Vokes
|
||||
Twitter: @silentbicycle
|
||||
|
||||
|
||||
## Judges' comments:
|
||||
### To use:
|
||||
|
||||
make
|
||||
./prog < example-1.txt
|
||||
|
||||
### Try:
|
||||
|
||||
./prog < example-2.txt
|
||||
./prog < example-tab.txt
|
||||
./prog < ioccc.txt
|
||||
|
||||
### Selected Judges Remarks:
|
||||
|
||||
What this program does is not witchcraft and there are no spectres, but you
|
||||
might have a meltdown trying to work it all out.
|
||||
|
||||
This entry is designed to mislead in many ways. However, if you find yourself
|
||||
wanting to know the possibilities for navigating a graph, you will get the
|
||||
answer you seek with no hocus pocus.
|
||||
|
||||
|
||||
## Author's comments:
|
||||
Introduction
|
||||
------------
|
||||
|
||||
This program reads a directed graph (as lines with integer node IDs),
|
||||
and prints the graph's nodes in reverse-topologically sorted order,
|
||||
grouped into strongly connected components. Given a set of nodes
|
||||
representing targets and edges representing dependencies between them,
|
||||
it produces a build order with any dependency cycles gathered.
|
||||
|
||||
For example, the following input (provided as `example-1.txt`):
|
||||
|
||||
0 4 8
|
||||
1 0
|
||||
2 1 3
|
||||
3 2
|
||||
4 1
|
||||
5 4 6
|
||||
6 5 2
|
||||
7 3 6 7
|
||||
|
||||
would be interpreted as:
|
||||
|
||||
0 -> 4, 8
|
||||
1 -> 0
|
||||
2 -> 1, 3
|
||||
3 -> 2
|
||||
4 -> 1
|
||||
5 -> 4, 6
|
||||
6 -> 5, 2
|
||||
7 -> 3, 6, 7
|
||||
|
||||
So, node 0 has edges to / depends on nodes 4 and 8, node 1 depends on
|
||||
node 0, and so on. Then, it groups the graph's nodes into
|
||||
strongly connected components and prints them in reverse-topologically
|
||||
sorted order:
|
||||
|
||||
0: 8
|
||||
1: 0 1 4
|
||||
2: 2 3
|
||||
3: 5 6
|
||||
4: 7
|
||||
|
||||
It uses Tarjan's strongly connected components algorithm for the
|
||||
grouping and reverse-topological sorting, along with a bonus hidden
|
||||
implementation of counting sort, which sorts each group.
|
||||
|
||||
For other details about the input format, see "Issues and
|
||||
Limitations".
|
||||
|
||||
|
||||
Building
|
||||
--------
|
||||
|
||||
To build:
|
||||
|
||||
${CC} -o prog prog.c -std=c11 -O3 \
|
||||
-Wall -Wextra -pedantic -Wno-missing-prototypes
|
||||
|
||||
`-Wno-missing-prototypes` is necessary because there aren't any
|
||||
prototypes. (They would put the program well over the size limit.)
|
||||
|
||||
Note: The program can also be built with `-std=c99` or `-std=c89`.
|
||||
|
||||
If building with `-Weverything`, then `-Wno-strict-prototypes`
|
||||
may also be necessary -- the function pointer declarations for
|
||||
`_` and `B` may get warnings otherwise, for reasons described
|
||||
under "Obfuscations".
|
||||
|
||||
|
||||
Obfuscations
|
||||
------------
|
||||
|
||||
- This entry uses functions that have a variable number of arguments,
|
||||
but despite what the rules say, there is no need to be careful about
|
||||
`va_list` implementation differences. :) . There are several
|
||||
references to a function pointer, `_`, but it's called with different
|
||||
numbers of arguments in different places. (In particular, look at
|
||||
`spell`.) Because the function pointer declaration has an empty list
|
||||
of parameters, the argument count and types are unconstrained. `_` is
|
||||
set to different functions in several places, but it is always called
|
||||
with appropriate argument(s) for its possible current functions. This
|
||||
is allowed by the standard -- The section on F,I,N,D,M,Y,C,L,U,E has
|
||||
further details.
|
||||
|
||||
- It uses `_` in three different scopes: as a goto label (function
|
||||
scope), as an enum name, and a `_` function pointer (which is required
|
||||
to have file scope, since it starts with '_'). There are also other
|
||||
`_`s: it appears in a string, obscured by a headecimal escape sequence
|
||||
(`\x5f`), and the cauldron is supported by a giant underscore.
|
||||
(Does this program qualify for Best One Liner?)
|
||||
|
||||
- Most of the variables are not only global, but used for unrelated
|
||||
purposes at different times, so just renaming them while studying the
|
||||
program should make it even more confusing. The few variables local to
|
||||
functions have their names reused for different things in other
|
||||
functions.
|
||||
|
||||
- There is an enum early on that defines several single-letter
|
||||
identifiers: F,I,N,D,M,Y,C,L,U,E. These are used for array offsets,
|
||||
both individually and in combination. The first several values are
|
||||
also a clue: ISO/IEC 9899:1999 chapter 6.7.5.3 verse 14 describes how
|
||||
function declarators with an empty parameter list behave. (As does
|
||||
3.5.4.3 for ANSI C, which explains the 0x3543 that appears soon
|
||||
after.)
|
||||
|
||||
- Several parts of the program's state are stashed in otherwise unused
|
||||
offsets of the node arrays. These locations are accessed in multiple
|
||||
ways, such as using `I[p]` (where I == 7) as well as `p[F+L]` (6+1),
|
||||
or `b[M-N]` (14-5) and `U[b]` (where U == 9).
|
||||
|
||||
- The other identifiers are misleading, punny, or both. `spectre` does
|
||||
not exploit CVE-2017-5753 or CVE-2017-5715, for example -- it just fits
|
||||
the witch theme. `cast` doesn't cast, `hex` has nothing to do with
|
||||
hexadecimal, `bubble` is not bubble sort, there is no undefined
|
||||
behavior in `nasal_demons`, and `main` has absolutely nothing to do
|
||||
with a hand.
|
||||
|
||||
- For well-formed input, how the program determines when to exit is a
|
||||
bit obscure. `main` ends with a `goto` leading back to an earlier `_`
|
||||
label, so it just loops forever, and `exit` only appears in code paths
|
||||
related to error-handling. It looks like `cast` calls `meltdown` with
|
||||
its second argument set to 0, which would call `exit`, but running in
|
||||
gdb with a breakpoint on `cast` reveals that it isn't being called...
|
||||
|
||||
- Instead of using `isdigit()`, the program checks the numeric value of
|
||||
each `char`, and literals that would suggest comparing against e.g. '0'
|
||||
are specified in octal in one place, and produced by arithmetic using
|
||||
the enum elsewhere.
|
||||
|
||||
- Common conventions are subverted: `i` is not a loop index, `argv` and
|
||||
`argc`'s names are swapped.
|
||||
|
||||
- `NULL` does not appear in the program. Instead, `argc[argv]` (which is
|
||||
required to be a null pointer) is saved and passed to where its value
|
||||
is needed.
|
||||
|
||||
- Oh, and the program is squashed into the shape of a bubbling cauldron,
|
||||
on top of a giant underscore, so there's that.
|
||||
|
||||
|
||||
Issues and Limitations
|
||||
----------------------
|
||||
|
||||
- Despite appearances, it does not handle numbers in hex, or provide
|
||||
a `curses(3)`-based interface.
|
||||
|
||||
- The expected input format is zero or more lines of space-separated
|
||||
integers. If other characters appear in the input, it will either
|
||||
reject the input entirely and exit with a non-zero status, or skip
|
||||
number(s) adjacent to the non-digit characters, depending on where the
|
||||
characters appear. Tabs and multiple consecutive spaces are handled
|
||||
correctly, however.
|
||||
|
||||
- Individual lines of input longer than `0x3543 - 1` bytes will be
|
||||
split and processed as if they were multiple lines of input, which can
|
||||
produce incorrect results. This magic number's significance is
|
||||
described earlier.
|
||||
|
||||
- The algorithm expects its input to represent a fully connected graph.
|
||||
While the output is otherwise topologically sorted, if there are nodes
|
||||
completely unconnected to the rest of the graph (with or without
|
||||
self-cycles), they will be output as soon as they are processed --
|
||||
this means that, when there are disconnected nodes, reordering the
|
||||
input lines can produce different output. Addressing this by adding
|
||||
another pass is would put the program over the size limit.
|
||||
|
||||
- While the node IDs don't need to be consecutive or start at 0, the
|
||||
implementation doesn't have special handling for sparse graphs. If you
|
||||
give it a graph with nodes numbered 0 and 2147483647, it will attempt
|
||||
to allocate sufficient memory (potentially around 32 GB) for the
|
||||
entire range of graph nodes, even if those are the only ones. If
|
||||
memory allocation returns NULL, it will gracefully exit, otherwise it
|
||||
will succeed, eventually, perhaps after a great deal of swapping.
|
||||
|
||||
- Node IDs >= 2147483648 will cause the program to print an error
|
||||
message and exit with a non-zero status. This shrinks the code that
|
||||
detects overflowing the array size by a bit.
|
||||
|
||||
- A very large group of nodes in a cycle can cause a stack overflow.
|
||||
This typically takes over 100,000 nodes, and depends on the order the
|
||||
nodes are visited. Addressing this would put the program over the size
|
||||
limit.
|
||||
|
||||
- The implementation depends on the characters '0', '1', ... '9' having
|
||||
the values 48 through 57, rather than using `isdigit()`. As noted
|
||||
above, this program has nothing to do with a hand.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
<!--
|
||||
(c) Copyright 1984-2018, [Leo Broukhis, Simon Cooper, Landon Curt Noll][judges] - All rights reserved
|
||||
This work is licensed under a [Creative Commons Attribution-ShareAlike 3.0 Unported License][cc].
|
||||
|
||||
[judges]: http://www.ioccc.org/judges.html
|
||||
[cc]: http://creativecommons.org/licenses/by-sa/3.0/
|
||||
-->
|
||||
@@ -0,0 +1,16 @@
|
||||
11111111 22222
|
||||
11 22 22
|
||||
11 22 22
|
||||
11 22 22
|
||||
11 22 22
|
||||
11111111 3333 33 22222
|
||||
333 333
|
||||
33
|
||||
33
|
||||
333 333
|
||||
4444 44 33333 5555 55
|
||||
444 444 555 555
|
||||
44 55
|
||||
44 55
|
||||
444 444 555 555
|
||||
44444 55555
|
||||
@@ -0,0 +1,47 @@
|
||||
#include <stdio.h>
|
||||
#include <string.h>
|
||||
#include <stdlib.h>
|
||||
typedef unsigned
|
||||
long W; static
|
||||
W*i,t,c,h,e,r,y,**a,*b,*o,*u,*n,*d,*s;enum
|
||||
_ {F=6 , I=7,N= 5 , D = 3 ,M=14
|
||||
,Y=0 , C=8,L = 1 , U = 9 , E=4};
|
||||
static void (* _ ) ( ) ; static void*(*B)(),*T;
|
||||
static char m[0x3543],*Z;void *meltdown(void *p,size_t
|
||||
sz){ void *z=realloc(p,sz);if(!z||!sz)exit(n?y!=*n:I-F);
|
||||
return z;}void magic(W*p){W j;for(j=0;j<p[F];j++){W*v=T,Q=
|
||||
p[M+j];W*J=a[Q];if(N[J]==~0LU){ _ (Q);v=&I[J];}else if(J[D])
|
||||
{v=&N[J];}if(v&&I[p]>*v)I[p]=*v;}}void cast(void){B(i,Y);}void
|
||||
spell(W G,W H){ _ (); _ (H); _ (H, G); _ (H); _ (G);}void witch(
|
||||
void){e=n[--E[b]];a[e][D]=0;if(b[C]>=U[b]){c=2*(b[C+L]?b[U]:1);o=B
|
||||
(d,c *sizeof*o);u=B(s,c*sizeof*o);b[M-N]=c;d=o;s=u;}d[b[N+D]++]=e;if
|
||||
(e>y)y=e;}void*brew(void*g,size_t l){puts(l?"":"Out of range.");exit
|
||||
(g?1:1);}void newt(W *p){F[p]=0;N[p]=I[p]=~F[p];}void bubble(W H){for
|
||||
(t=0;t<H;t++){s[i[d[H-t-1]]---1]=d[H-t-1];}}void boil(W G){for(t=0;t<
|
||||
G-1;t++){i[t+1]+=i[t];} _ =bubble;}void hex(W G,W H){for(t=0;t<H?G:Y;t++
|
||||
){i[d[t]]++;} _ =boil;}void nasal_demons(W G){for (t=Y;t<G;t++)i[t]=0; _
|
||||
=hex;}void toil(void){i=B(i,y*sizeof*i); _ =nasal_demons;}void bat(W l)
|
||||
{C[b]=0; _ =witch;do _ ();while(e!=l);y++;if(!y)B=brew; _ =toil;spell (C
|
||||
[b],y);printf("%lu:",b[L]++);for(y=0;y<C[b];y++){printf(" %lu",s[y]);}y=
|
||||
0;puts("");}void potion(W l){W*p=a[l];if(p[N]!=~0LU)return;p[F+L]=h;p[N]
|
||||
=h;p[D]=1;h++;n[b[L+D]++]=l;if(E[b]==r){r*=2;n=B(n,r*sizeof*n);}magic(p)
|
||||
;if(I[p]==p[N]){bat(l);} _ =potion;}void O(void){n=B(n,2*sizeof(*n));Y[n
|
||||
]=r;if(a&&a[t]){r=2;b=a[t]; _ =potion;b[L+C]=b[L]^=b[L];E[b]=1;for(y=0;y
|
||||
<*n;y++){if(a[y]){ _ (y);}}} _ =cast;h=0;}void toad(W g,W j,W*l){o=B(a
|
||||
[g],((a[g]?a[g][F]:0)+j+M)*sizeof*o); _ =newt;if(!a[g]){ _ (o);}for(y=
|
||||
0;y<j;y++){o[F[o]+F+C]=l[y];o[F]++;if(l[y]==g){continue;}u=B(a[l[y]]
|
||||
,((a[l[y]]?a[l[y]][F]:Y)+M)*sizeof*u);if(!a[l[y]]){ _ (u);}a[l[y]]
|
||||
=u;}y=0;a[g]=o;}void familiar(void){W**w;e=r;if(!r){r=1;}while
|
||||
(r<=t){r*=2;if(!r){B=brew;break;}}w=B(a,r*sizeof*a);if(!
|
||||
Z){Z="\x5f";}for(y=e;y<r;y++){y[w]=T;}y=0;a=w;
|
||||
_ (Y[i] ,c-1,&i[1]);}void spectre(void ){if((W)
|
||||
*Z-060 >011){
|
||||
return;} _ =toad
|
||||
;i[c]=( W)atoi(
|
||||
|
||||
Z);if(i[c]>t){t=i[c];}c++;if(c==h){i=B(i,2*h*sizeof*i);h*=2;}y=i[c-1];if
|
||||
((Z=strtok(T," \t"))){if(U>=(W)*Z-I*I+L) _ =spectre;}}int main(int argv,
|
||||
char**argc){h++;if(argc){T=argc[argv];} _:_ =O;i=(B=meltdown)(T,h*sizeof
|
||||
*i);while(*argc||Z){c=0;*argc=fgets(m,sizeof(m),stdin); _ =spectre;if(!*
|
||||
argc){Z=T;goto _ ;}Z=strtok(*argc,"\t ");while(Z&&(W)*Z-(M*D+F)<=U){ _ (
|
||||
);}if(t>=r)familiar();else if(c>0){ _ (i[Y],c-1,&i[1]);}} _ ();goto _ ;}
|
||||
Reference in new issue
Block a user