The problem was that the int * needed to be a long *. It became apparent
to me when evaluating it with lldb as I noticed a pointer was long, not
an int. This does not cause a problem with linux. I have no 32-bit
system to test but I don't believe this will be an actual problem.
Split judges' comments to be a to build, try and judges' comments. The
to build section already existed.
Also added ./ in front of the binary name so commands would actually
work.
This was fun to do even though it's also a very simple one liner plus
special handling in the Makefile (the latter part is so you can use it
the exact same way as the original). The original code just #included
/dev/tty. This does something just as magical! It can be used like:
make alt
# some C code
^D
./spinellis
For instance:
make alt
#include <stdio.h>
int main() { puts("hello world"); }
^D
./spinellis
Now those with clang can enjoy the entry without any functional
difference.
I have a very twisted point to make about the original version and this
version too: with a very slight change one can actually make a C++
version. Ick! :-)
The type of the second and third arg of main() were not char ** which
caused clang to have a fit. In gcc this is not a problem but it printed
gibberish nonetheless.
Changing the type of the second and third arg to compile with clang and
it printed the same (or similar?) gibberish as it did with gcc.
Adding a new function (pain() as it's annoying that clang requires
second, third and fourth args to main() to be 'char **'s even though in
this case it didn't work anyway) and calling it from main with the
appropriate args fixes the problem.
New sections and statuses.
Added some entries. I am going through all entries to find more to add
but I ended up fixing an entry which I wish to commit so the next
updates to this file will be on a different branch and most likely later
on today.
In general the compiler warnings should be ignored. Only if the entry
does not work and even then only sometimes should they be fixed.
Sometimes fixing them will introduce bugs and/or crashes. Sometimes a
fix which works correctly (see my fixes to 1986/holloway and
1998/schnitzi for two examples) will introduce new warnings which MUST
NOT be fixed. Thus a general section warning against fixing warnings
lest they cause other bugs which might or might not cause other warnings
to fix (if even possible) to make it work without warnings is something
that should be there. I also noted how although some entries in the list
do have warnings noted we will not try and keep them up to date as
different compilers and almost certainly platforms (e.g. data type
sizes) generate different warnings. Sometimes this does mean that an
entry will only work on certain platforms and some might or might not be
fixable but most likely they cannot be fixed easily and even if they can
be it almost certainly will be just as non-portable (importable ? :-) ).
I did update the list of warnings in one of the entries I fixed however.
Increased header (text size) of status lines..
Make 'Status' 'STATUS'.
Added an entry (1989/paul). I am actually aware of more entries that I'm
working on (and I'm working on this one too) that do not work and/or
crash but I've not yet put in the file as I sillily (which amusingly
macOS vim dictionary does not even recognise as a word but it absolutely
is and OED will confirm it!) did not note earlier (which means I have to
go through all entries for the third or fourth time .. if not more times
for some!).
Added some statuses. Some entries can have more than one status now: the
idea is sometimes they have more than one problem OR the different
statuses are related in the entry.
Added some bold and italic in some places to make things stand out
better. The same with making some words all caps.
Add years without an IOCCC to make it easier to recognise that the year
isn't missing but because there simply was no contest that year.
Possibly other things.
Additionally I have had the thought of making a table of contents for
each status (in the list of statuses) so one can jump to the entry
they're interested in and so one can see the different entries at a
glance. There would be a problem, maybe, with entries that have more
than one status but that could be easily addressed by having it in both
statuses (having a note under one would mean we would have to
arbitrarily select which list to add to and also would make it harder to
find though maybe only slightly).
For Makefiles that have alt related rules, moved
the related rules under the alt rule section.
In some cases where there is no alt code,
removed alt rules and/or targets.
Changed the position of the everything Makefile rule
in select Makefiles to be consistent with other makefiles.
Fixed Makefile for 1986/stein where everything was not
everything (did not depend on alt).
Landon Curt Noll