One of the lines in the fix (which is the same code as the original) had
an extra space in front of the first char which showed a difference. Not
a big deal but fixes should modify as little as possible.
The #define char can be used as long as main() does not have two args
which it does not need to work. But since some versions have an
additional defect that main() can only have 0, 2 or 3 args (but see
below) it was made so that main() no longer has any args: instead the
'int i' was moved to be inside main() and set to 1 (it cannot be 0).
The version where I noticed that clang whines about the number of args
to main() will whine if it has, say, 4 args, but it will not if it has
1 and it has never whined (as an error) about passing too many args to a
function. Thus on line 29 the call to main() still passes the same
variable to main().
If clang or the ANSI C committee ruin more perfectly fun programs (both
of which seem possible) then the #define char could be renamed say to
shar or else commented out with an adjustment to 'k' (see the diff for
this commit below for where I originally had it to what it is now) or
alternatively (at the expense of making it even less like the original
in obscurity) one could remove the parameter to main() on line 29.
The way 'k' changed in this commit:
#define char k['a']
#define union static struct
extern double floor(double);
double (x1, y1) b;
-/*char x {sizeof(
- double(%s,%D)(*)()) */
-int
-k['a'] = {sizeof(
- int(*)())
+char x {sizeof(
+ double(%s,%D)(*)())
,};
struct tag{int x0,*xO;};
but now it's improved upon.
When I restored the macros it allowed for reinstating the 'union'
instead of 'static struct' and it also allowed for reintroducing the 'x'
(which is '=') in that line so that it looks just like the original:
union tag u x{4};
For documentation purposes this was added in the thanks file (in the
same part of that entry, the making it look more like the original which
is a worthy goal) as well.
I was able to bring back some code and only had to comment out one part
and make a minor change to another another. Originally the code had:
extern int floor;
but this is not possible in modern systems so it was changed to:
extern double floor(double);
The
double (x1, y1) b;
could be brought back, changed from:
int b,
(the comma is not a typo there).
Now it looks rather more like the original.
The thanks-for-fixes.md file was updated here, including a diff to try
(to see what had to be done to fix the entry for modern systems) but I'm
afraid it has a minor change in another entry, something I accidentally
left out of 1984/mullender.
To make it look more like the original but to still work with compilers
without -traditional-cpp (which clang does not support) and other
defects with clang (including one that was problematic in linux but not
macOS) code that used macros had to be modified and used directly. But I
removed the macros because of this. Now they are added back even though
they are unused, just to give it a more authentic, original look.
The thanks-for-fixes.md file was updated for this, both formatting and
otherwise, but an unfortunate thing is that another entry was also
modified in there. This is because I was aiming to just do format fixes
in 1984 in one pull request to save time but then I came across this and
decided to fix it and this should be in a single pull request.
Something I noticed is that the fix for linux clang _appears_ to not be
needed at least with clang 16.0.6 but what the difference is is just
extra warnings. I cannot imagine I changed it just for that so I have
left that change in in case there was a problem in earlier versions or
something else I do not recall. It should be noted that without the
change at least with clang 16.0.6 it appears to work just fine. It is
unclear if it should be changed back but again as I can't imagine that I
would have changed it just for warnings I think it's wiser not to.
Although my change of not requiring -traditional-cpp worked in macOS it
turns out one change had to be made for clang in linux which has now
been done.
This was fun to fix. What prompted me to do so is that I noticed that
the patch from Yusuke Endoh actually doesn't work in fedora linux. It never
worked with clang as it required -traditional-cpp and also had
non-standard second and third args type to main (not a char ** but
implicit int). No more. This entry now works with both linux and macOS!
I was able to remove all the macros as they were problematic and not
needed. The code that used them was updated to be what was necessary.
Add to Makefile inclusion of stdio.h and math.h (printf, floor).
Some systems require -lm so that was also added to the Makefile.
Very little else was required to make it work.
The decot.alt.c is the version patched by Yusuke but fixed by me to
compile with fedora's gcc.
Removed this entry from bugs.md.
This will not compile with clang which is actually what gcc is under
macOS. Unfortunately clang does not support -traditional-cpp which this
entry requires for modern systems.
We would like to thank Yusuke Endoh for the patch to get this to compile
with gcc. Thank you very much Yusuke!
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?).