-
Notifications
You must be signed in to change notification settings - Fork 48
/
Copy pathbugs.html
3713 lines (3585 loc) · 209 KB
/
bugs.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!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:[email protected]&display=swap" rel="stylesheet">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
<title>The International Obfuscated C Code Contest</title>
<link rel="icon" type="image/x-icon" href="./favicon.ico">
<meta name="description" content="Bugs and (mis)features of IOCCC entries">
<meta name="keywords" content="IOCCC, Bugs and (mis)features, bugs, features, misfeatures, mis-features">
</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/gen-top-html.sh -->
<!-- The content of main section of this web page came from: bugs.md -->
<!-- -->
<!-- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
<!-- !!! Do not modify this web page, instead modify the file: bugs.md !!! -->
<!-- !!! Do not modify this web page, instead modify the file: bugs.md !!! -->
<!-- !!! Do not modify this web page, instead modify the file: bugs.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/index.html" class="sub-item-link">
Rules and 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="./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/index.html">
Rules and 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="./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>IOCCC entry Bugs and (mis)features</h2>
</div>
<!-- END: this line ends content from: inc/header.default.html -->
<!-- START: this line starts content from: inc/navbar.empty.html -->
<div class="navbar">
<a class="Right" href="https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.ioccc.org%2Fbugs.html">✓</a>
</div>
<!-- END: this line ends content from: inc/navbar.empty.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 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
<!-- BEFORE: 1st line of markdown file: bugs.md -->
<h1 id="bugs-and-misfeatures">Bugs and (mis)features</h1>
<h2 id="table-of-contents">Table of Contents</h2>
<p>If you are going to try and fix any bugs <strong>PLEASE READ THE NEXT SECTIONS <em>FIRST</em></strong>.
If however you want to jump to a specific year or you have already read the
below and you wish to help with a year, you can use these links:</p>
<ul>
<li><a href="#1984">1984 entries</a> | <a href="#1985">1985 entries</a> | <a href="#1986">1986 entries</a> | <a href="#1987">1987 entries</a></li>
<li><a href="#1988">1988 entries</a> | <a href="#1989">1989 entries</a> | <a href="#1990">1990 entries</a> | <a href="#1991">1991 entries</a></li>
<li><a href="#1992">1992 entries</a> | <a href="#1993">1993 entries</a> | <a href="#1994">1994 entries</a> | <a href="#1995">1995 entries</a></li>
<li><a href="#1996">1996 entries</a> | <a href="#1998">1998 entries</a> | <a href="#2000">2000 entries</a> | <a href="#2001">2001 entries</a></li>
<li><a href="#2004">2004 entries</a> | <a href="#2005">2005 entries</a> | <a href="#2006">2006 entries</a> | <a href="#2011">2011 entries</a></li>
<li><a href="#2012">2012 entries</a> | <a href="#2013">2013 entries</a> | <a href="#2014">2014 entries</a> | <a href="#2015">2015 entries</a></li>
<li><a href="#2018">2018 entries</a> | <a href="#2019">2019 entries</a> | <a href="#2020">2020 entries</a></li>
</ul>
<p>Jump to: <a href="#">top</a></p>
<h2 id="please-read-the-next-sections-if-you-wish-to-help">PLEASE read the next sections if you wish to help</h2>
<p>There are a number of known problems with IOCCC entries: many of
which have to do with differences between today’s compiler environments
and those of today. In some cases the original code has a bug, some
of which were recently discovered and many of which were fixed. In some cases
attempt to port older code to more modern environments introduced bugs.</p>
<p>The following is a known list of <strong>BUGS and (mis)FEATURES</strong> in IOCCC entries.</p>
<p>Can you fix/improve entries not under the INABIAF (it’s not a bug it’s a
feature)? You are <strong>VERY WELCOME</strong> to try.</p>
<p>As far as how to help: please submit your fixes in a <a href="https://github.com/ioccc-src/winner/pulls">GitHub pull
request</a> (with ONE PULL
REQUEST <em>PER</em> FIX, please)!</p>
<p>We will be <strong>happy to credit anyone who submits successful <a href="https://github.com/ioccc-src/winner/pulls">GitHub pull
requests</a></strong> in the
<a href="thanks-for-help.html">thanks</a> file. If you’re the author of an entry
that win the IOCCC, we will add a link to your winning entries in the file
(if you’re not an author, we can add a link to your GitHub page or personal
website if you have one, should you wish).</p>
<p>If you do fix an entry please feel free to delete the entry from this file!
Otherwise if you wish to not worry about it we can do that to make sure the
format is consistent and clean.</p>
<p>THANK YOU!</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="to-the-winning-authors">To the winning authors:</h2>
<p>If you’re the author of an entry that has been fixed and you find it against
your liking <strong>PLEASE</strong> let us know and we’ll be happy to undo any fixes even if
it takes away some instructional value or even usability. _In this case we’re
<strong>VERY SORRY</strong> about it: it’s a fine line, we know, and we tried to use careful
judgement but invariably some might have been the wrong decision. Thank you for
understanding!</p>
<p>When working on getting entries to compile, sometimes some things were changed
that should not have been. Also the definition of <code>INABIAF</code> was changed a number
of times. At one point some things were changed to a bug (a usability problem
for example) to be fixed but when looking at the index.html file it was noticed
it was documented so the fixes were undone at that point.</p>
<p>Jump to: <a href="#">top</a></p>
<h3 id="on-all-fixes-improvements-changes">ON <strong>ALL</strong> FIXES / IMPROVEMENTS / CHANGES</h3>
<p>Make <strong>ABSOLUTE CERTAIN</strong> that you test the entry <em>BEFORE</em> <strong>AND</strong> <em>AFTER</em> your
changes! This includes output and the same input functionality! Sometimes it
might seem to be fine but is actually not! We will note some where this is known
to happen (if it’s not yet fixed). This has actually already happened to us.
Sometimes it is okay: some entries are known to not work but they can still have
improvements (rarer situation but it’s happened). Some might have slightly
different output but which is not a problem for instance a newline after output.
This is not the most ideal but it is okay.</p>
<p>Make <strong>ABSOLUTE CERTAIN</strong> that you read the index.html file <em>BEFORE</em> your changes
as it’s important to see that the code is doing what it is supposed to. In the
case that it’s not obvious (some index.html files do not even have commands to
try or even explain how to use it!) then you should either skip the entry OR ask
someone who will know for instance the Judges.</p>
<p>Make <strong>ABSOLUTE CERTAIN</strong> that you read the next section, the list of statuses
and the related information, BEFORE you submit a pull request!</p>
<p><strong>BE VERY AWARE</strong> that sometimes fixing an entry for one platform will break it
under another so if you have more than one platform (e.g. macOS and linux) it
would be wise to test it under all that you have access to. Otherwise we can do
that. Of course if the entry does not work under any platform and you fix it for
one that’s more than fine (and it has been done numerous times).</p>
<p>Again, THANK YOU!</p>
<p>Jump to: <a href="#">top</a></p>
<hr>
<h1 id="list-of-statuses">LIST OF STATUSES</h1>
<h2 id="please-read-before-fixing">PLEASE READ BEFORE FIXING</h2>
<p><strong>BTW</strong>: You may skip if you’re only interested in knowing about entries with known issues.</p>
<p>Entries below have one or more of the following <em><strong>STATUS</strong></em> values. Please see
the text below for more information. If an entry has more than one status it
means that either they all apply or they complement each other.</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="general-notes-about-the-statuses-and-making-fixes">General notes about the statuses and making fixes</h2>
<p>Jump to: <a href="#">top</a></p>
<h3 id="compiler-warnings-are-very-rarely-a-problem">Compiler warnings are very rarely a problem</h3>
<p>In general warnings should NOT be addressed. The only time they should be
CONSIDERED is when the entry does not work. However note that sometimes trying
to fix the warnings will actually introduce bugs! Other times ‘fixing’ them will
break the entry (see below).</p>
<p>Below in some entries we do list some warnings that definitely should be ignored
(including some introduced by fixes) but we do not list them all: trying to keep
track of them all would be impractical especially as different compilers give
different warnings.</p>
<p>Another type of warning that would be hard to keep track of is different data
sizes on different platforms. These tend to be required at the risk that
sometimes the entry will not work for certain platforms, some of which might or
might not be fixable; a good example where it was required to change and is okay
is the fix of the segfault in macOS of
<a href="https://github.com/ioccc-src/winner/blob/master/1989/paul/paul.c">1989/paul</a>: changing the <code>int *</code> to a <code>long *</code>
was required and it works just as well with linux.</p>
<p>But even if they are fixable (which will likely be hard to do) it’s almost
certain that such code would be just as non-portable (importable ? :-) ).</p>
<p>In rare cases they are valid. For instance in linux the following
warning in <a href="https://github.com/ioccc-src/winner/blob/master/1985/applin/applin.c">1985/applin</a> with gcc:</p>
<pre><code> applin.c:1:78: warning: incompatible implicit declaration of built-in function 'execlp' [-Wbuiltin-declaration-mismatch]
1 | main(v,c)char**c;{for(v[c++]=strdup("Hello, world!\n");(!!c)[*c]&&(v--||--c&&execlp(*c,*c,c[!!c]+!!c,!c));**c=!c)write(!!*c,*c,!!**c);}
| ^~~~~~</code></pre>
<p>and this is is kind of like the fix to
<a href="https://github.com/ioccc-src/winner/blob/master/1984/anonymous/anonymous.c">1984/anonymous</a>. In the case of <code>1984/anonymous</code> it
was a bit more involved but with <code>1985/applin</code> one need only add to the Makefile
<code>-include unistd.h</code>. So there are some cases where fixing warnings can fix a
problem but in general they should be ignored even if they’re annoying.</p>
<p>Hopefully with the example entries listed above you get the idea.</p>
<p>Jump to: <a href="#">top</a></p>
<h3 id="general-request-on-original-code">General request on original code:</h3>
<p>If you’re fixing an entry please make as <em>FEW CHANGES AS POSSIBLE</em>! This is to
make it as close to the original but allowing it to work. This might be less of
a problem when providing alternate versions but it might still be nice to have
it as close as possible to the original. See also below two points.</p>
<p>Jump to: <a href="#">top</a></p>
<h3 id="request-for-one-liners">Request for one-liners:</h3>
<p>For one-liners <em>PLEASE KEEP THE FILE ONE LINE IF AT ALL POSSIBLE</em>! See the
<a href="next/guidelines.html">guidelines</a> for what constitutes a one-liner. If it needs an
include you can update the Makefile <code>CINCLUDE</code> variable. For instance if it
needs <code>stdio.h</code> you could do <code>-include stdio.h</code>. Please leave a space after the
<code>=</code> in the Makefile. You may also have extra long lines if this seems useful to
make it a one-liner even if it kind of makes it longer than what the judges
consider a one-liner, at least within reason. Thank you!</p>
<p>Jump to: <a href="#">top</a></p>
<h3 id="on-layout-of-program-source">On layout of program source:</h3>
<p>If you make changes <em>PLEASE TRY AND KEEP THE SOURCE CODE LAYOUT AS CLOSE TO THE
ORIGINAL AS POSSIBLE</em>. This might not always be possible and if you have an
editor that does formatting it can cause problems. Sometimes formatters can even
break code! Some have experienced this many times with vim so he tends to
disable all format options when formatting code. In vim you should be able to do
that with:</p>
<pre><code> :set formatoptions=</code></pre>
<p>Jump to: <a href="#">top</a></p>
<h2 id="status-known-bug">STATUS: known bug</h2>
<p><strong>Please help us fix</strong>!</p>
<p>Entries with this status have one or more bugs that need to be fixed. Are you
able to fix it? We welcome your help!</p>
<p>An important point to note is that there is a very fine line when fixing bugs
where it might sometimes border on tampering with the program. And after all,
these are not meant to be maintainable or even good programming style! Use
careful judgement when fixing bugs please!</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="status-possible-bug">STATUS: possible bug</h2>
<p>Jump to: <a href="#">top</a></p>
<h3 id="system-dependent-bug-possibly">System dependent bug possibly</h3>
<p><strong>Please help test, and if necessary fix this bug</strong>!</p>
<p>Entries with this status might or might not have a bug possibly depending on the
system. In these entries it’s unknown if there is a bug and sometimes it’s
because we do not remember and sometimes we don’t have the appropriate system or
environment to test and fix any possible problems.</p>
<p>Jump to: <a href="#">top</a></p>
<h3 id="status-might-not-be-completely-functional">STATUS: might not be completely functional</h3>
<p><strong>Can you confirm there is a bug?</strong></p>
<p>Although these entries <em>appear</em> to work for one or more reasons we’re unsure if
they are completely functional. Can you confirm this? Please let us know so we
can fix it!</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="status-probable-bug">STATUS: probable bug</h2>
<p>Jump to: <a href="#">top</a></p>
<h3 id="possible-system-dependent-bug">Possible system dependent bug</h3>
<p><strong>Please help test and if necessary fix this bug</strong>!</p>
<p>Entries with this status almost certainly have a bug or some other problem. The
issue or issues might depend on the system much like the above <em>STATUS: possible
bug (possibly depending on system)</em>.</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="status-doesnt-work-with-some-platforms">STATUS: doesn’t work with some platforms</h2>
<p><strong>Please help us fix this bug</strong>!</p>
<p>Entries with this status do not work under some OSes and/or architectures (and/or
something else?). Please help us to fix it!</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="status-doesnt-work-with-some-compilers">STATUS: doesn’t work with some compilers</h2>
<p><strong>Please provide alternative code or fix for more compilers</strong>!</p>
<p>Some entries do not work with some compilers. A good example is
<a href="https://github.com/ioccc-src/winner/blob/master/1992/lush/lush.c">1992/lush</a> which uses error messages from the compiler to
generate its output.</p>
<p>If you can provide code that works for multiple compilers without too much
tampering this is okay though it’s probably not possible with the above
mentioned entry; otherwise it would be better to provide alternate code. In some
cases it might be better to provide alternate code anyway. Use a judgement call
here as best you can manage.</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="status-main-function-args-not-allowed">STATUS: main() function args not allowed</h2>
<p><strong>Please help us fix the main() function</strong>!</p>
<p><strong>NOTE</strong>: it appears that most if not all of these have been fixed except perhaps
for <a href="https://github.com/ioccc-src/winner/blob/master/1989/westley/westley.c">1989/westley</a> but this has probably been fixed as
much as possible given the nature of how it generates code: the entry itself
compiles but two versions of code it generates does not work with clang.</p>
<p>However some still might have problems of some kind or another and some might
not yet be located as an additional defect of clang was noticed where <code>main()</code>
is not allowed four args or one arg (see below).</p>
<p>This is what the status means, however.</p>
<p>Entries with this status have a problem in that the args to main() are not of a
specific type or there are too many due to this being allowed in earlier C. Some
compilers like clang have a defect where they do not allow this and some
versions have an additional defect where they only allow 0, 2 or 3 args, the
latter of which affected <code>1989/westley</code>, so these entries do not work with
clang.</p>
<p>Looking at the source
code of clang, it appears that there is no way to override the requirement of
arg types so these entries will fail to compile with clang. That’s why in some
entries the fix was done with a new function, often called <code>pain()</code> :-)</p>
<p><strong>NOTE for macOS users</strong>: please be aware that <em>gcc</em> under macOS <strong>is actually
clang</strong> despite the fact it might appear to be gcc: no symlink and both gcc and
clang exist but the gcc is clang which you’ll see if you run <code>gcc --version</code>.</p>
<p>A tip and some fix methods: in the older days args to <code>main()</code>
not given a type were implicit <code>int</code>s but when they’re required to be <code>char **</code>
this can cause a problem. In some cases it was possible to use a <code>char *</code> inside
<code>main()</code> (see <a href="https://github.com/ioccc-src/winner/blob/master/1989/tromp/tromp.c">1989/tromp/tromp.c</a> and
<a href="1986/holloway/index.html">1986/holloway/holloway.c</a> for two examples though
done slightly differently). In other cases it was possible to dereference the
pointers to be used like an int and other times a cast was necessary. There are
various techniques to get these to compile. In some cases this introduced a
problem but typically if not always that problem exists with compilers that are
less strict.</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="status-main-has-only-one-arg">STATUS: main() has only one arg</h2>
<p><strong>Please help modify so that main() as 2 or 3 args</strong>!</p>
<p>Because some versions of clang complain about the number of args of <code>main()</code> and
in particular say (when it has four, for instance) that it’s only allowed to
have 0, 2 or 3 args, numerous entries had a second arg added to <code>main()</code> (if
they only had one). This is in case clang adds further restrictions which is not
impossible especially as it already claims having only one arg is not allowed.
At this time (04 Feb 2024) there is one entry known (it is possible that not all
were checked) that has this problem but it’s not as simple as the others to fix
without breaking it.</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="status-compiled-executable-crashes">STATUS: compiled executable crashes</h2>
<p><strong>Please help us fix this bug</strong>!</p>
<p>While such entries can compile, the resulting executable sometimes or always
crashes.</p>
<p><strong>NOTE</strong>: this does NOT apply to entries under the INABIAF status (though they’re
not mutually exclusive in some cases).</p>
<p>REMINDER: if you’re debugging a crash it will be very helpful to have <code>-O0 -g</code>
or if you can <code>-ggdb3</code> when compiling as that will help with debugging symbols.</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="status-uses-gets">STATUS: uses gets()</h2>
<p><strong>Please help us change use of gets() to fgets()</strong>, if possible.</p>
<p>Entries with this status use <code>gets()</code> which is unsafe because it has no limit on
the length of the string. Many were fixed but not all.</p>
<p>There’s a very good reason for this change even though it is bordering on tampering
entries: in modern systems one will get possibly alarming and certainly annoying
warnings during at least one of compiling, linking and execution. In macOS it’s
most annoying as it happens during execution (also compilation) with the warning
being interspersed with the output of the program, often causing confusing
output with the entry. A good example that was fixed is
<a href="https://github.com/ioccc-src/winner/blob/master/1990/tbr/tbr.c">1990/tbr</a>.</p>
<p>Some important notes on this status with respect to fixing / changing the
entries:</p>
<ol start="0" type="1">
<li><p>In some cases changing the entry to use <code>fgets()</code> will break the entry and in
some cases cause it to crash. Where this is known we will document it.</p></li>
<li><p>You <strong>MUST</strong> check the output before and after to make sure that it remains
the same. Sometimes the output might not be immediately obviously wrong but is.
We will document known examples as we come across them.</p></li>
<li><p><code>gets()</code> does NOT STORE the <code>'\n'</code> but <code>fgets()</code> DOES! This is one of the
reasons some of the entries break when changed to <code>fgets()</code>. Some of those have
been fixed but there are others that have not been.</p></li>
<li><p>Just because you don’t see the string <code>gets</code> in the code does not mean it’s
not used. It is after all the International <em>Obfuscated C Code</em> Contest! :-)
Sometimes it will be in the Makefile and other times it will be obfuscated in
other ways; a good example of that that was fixed is
<a href="1991/dds/index.html">1991/dds</a>: in this case the string was encrypted.
Compilers and linkers tend to warn about its use (and as noted in macOS it also
happens at execution) and this is a good way to find entries that use it even if
it’s not visible in the code.</p></li>
</ol>
<p><strong>NOTE</strong>: this status is <em>NOT necessarily mutually exclusive</em> with the <em>INABIAF</em>
(it’s not a bug it’s a feature) status. The reason for this is due to warnings
during compiling, linking and/or runtime, sometimes causing confusing output (as
noted above).</p>
<p>Sometimes <code>getline(3)</code> will work but note that this function also stores the
newline just like <code>fgets(3)</code>.</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="status-missing-files">STATUS: missing file(s)</h2>
<p><strong>Please help is by finding missing file(s)</strong>!</p>
<p>In these entries one file or multiple files are missing from the repo. In some
cases these files can be found on the <a href="https://www.ioccc.org">IOCCC website</a> but
in other cases they are entirely absent. In this case you’ll probably have to
contact the author (unless you are the author! :-) ).</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="status-missing-or-dead-link">STATUS: missing or dead link</h2>
<p><strong>Please help is fix missing or dead link(s)</strong>!</p>
<p>This is as they sound: a link is either missing or it’s no longer valid. In many
cases the <a href="https://web.archive.org">Internet Wayback Machine</a> will be very
useful but there happens to be numerous links that this is not helpful. In other
cases the URL has changed. Some of these have been discovered by the Internet
Wayback Machine with the orange status.</p>
<p>Jump to: <a href="#">top</a></p>
<h3 id="statuses-of-internet-wayback-machine-archive">Statuses of Internet Wayback Machine archive:</h3>
<ul>
<li>Green (3xx): redirect (this has been used to find changes in URL).</li>
<li>Orange (4xx): not found etc.</li>
<li>Blue: this is a good link (but note that this doesn’t mean that it’s correct!).</li>
</ul>
<p>The archive website will tell you if the link was never captured.</p>
<p>Jump to: <a href="#">top</a></p>
<h2 id="status-inabiaf---please-do-not-fix">STATUS: INABIAF - please <strong>DO NOT</strong> fix</h2>
<h3 id="inabiaf-its-not-a-bug-its-a-feature--">INABIAF: It’s not a bug it’s a feature :-)</h3>
<p>Entries with this status should NOT be touched (unless they have another status
that suggests that <em>that</em> issue can be changed): they are system specific by
design or are other things that are not actually bugs or bugs even if they
appear to be. Or they might be documented bugs or things that simply are part of
the entry. Nonetheless they are noteworthy.</p>
<p><strong>NOTE</strong>: the definition of this status changed over time. At one point it was when
something was noted by the author, the judges, a consequence of earlier
requirements for winning entries or the purpose was to do something that might
appear to be buggy. An example of system specific entries:</p>
<p><a href="https://github.com/ioccc-src/winner/blob/master/1984/mullender/mullender.c">1984/mullender</a> (see below for a
version that works in modern systems) is very system specific and was before
system specific winning entries were discouraged. This is an all time personal
favourite of Landon Curt Noll. Run the alternate code to understand why this
might be (along with how strange the source code is :-) ).</p>
<p>An example where a crash is not a bug: <a href="2019/endoh/index.html">2019/endoh</a> is
supposed to crash. There are others that are also supposed to crash or that are
known to segfault but are considered features.</p>
<p>An important note is that if the index.html of the entry has a bug status that
says it can be fixed it can be. Otherwise it should not be.</p>
<p>Nonetheless we challenge you to fix these entries for educational/instructional
value and/or enjoyment but we kindly request that you <strong>DO NOT</strong> submit a pull
request unless it’s a bug or (mis)feature we would like you to fix!</p>
<p><strong>NOTE</strong>: in the case of <code>gets()</code> we’ve fixed some to avoid the warning of the
compiler, linker or even during runtime, depending on the system. In <a href="1990/tbr/index.html">some cases
like 1990/tbr</a> the fix actually prevents confusing output (though that
was not the only fix made in that entry).</p>
<p>Jump to: <a href="#">top</a></p>
<h3 id="exception-your-own-entries">Exception: your own entries</h3>
<p>Of course if you’re the author you’re welcome to fix your own entry, prefer your
own fix or suggest that they’re fixed!</p>
<p>Jump to: <a href="#">top</a></p>
<hr>
<h1 id="list-of-entries-by-year-sorted-in-alphabetical-order-per-year">List of entries by year, sorted in alphabetical order per year</h1>
<hr style="width:10%;text-align:left;margin-left:0">
<div id="1984">
<h1 id="section">1984</h1>
</div>
<hr style="width:10%;text-align:left;margin-left:0">
<p>Jump to: <a href="#">top</a></p>
<div id="1984_decot">
<h2 id="decot">1984/decot</h2>
</div>
<p>Jump to: <a href="#">top</a></p>
<h3 id="status-inabiaf---please-do-not-fix-1">STATUS: INABIAF - please <strong>DO NOT</strong> fix</h3>
<h3 id="source-code-1984decotdecot.c">Source code: <a href="https://github.com/ioccc-src/winner/blob/master/1984/decot/decot.c">1984/decot/decot.c</a></h3>
<h3 id="information-1984decotindex.html">Information: <a href="1984/decot/index.html">1984/decot/index.html</a></h3>
<p>The purpose of this program is to print out what looks like a fragment of C
code. In particular you should see something like:</p>
<pre><code> $ ./decot
'",x); /*
\</code></pre>
<p>without a newline after the <code>\</code>. This is not a bug.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="1984_laman">
<h2 id="laman">1984/laman</h2>
</div>
<p>Jump to: <a href="#">top</a></p>
<h3 id="status-inabiaf---please-do-not-fix-2">STATUS: INABIAF - please <strong>DO NOT</strong> fix</h3>
<h3 id="source-code-1984lamanlaman.c">Source code: <a href="https://github.com/ioccc-src/winner/blob/master/1984/laman/laman.c">1984/laman/laman.c</a></h3>
<h3 id="information-1984lamanindex.html">Information: <a href="1984/laman/index.html">1984/laman/index.html</a></h3>
<p>This program will very likely crash or do something funny without an arg.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="1984_mullender">
<h2 id="mullender">1984/mullender</h2>
</div>
<p>Jump to: <a href="#">top</a></p>
<h3 id="status-inabiaf---please-do-not-fix-3">STATUS: INABIAF - please <strong>DO NOT</strong> fix</h3>
<h3 id="source-code-1984mullendermullender.c">Source code: <a href="https://github.com/ioccc-src/winner/blob/master/1984/mullender/mullender.c">1984/mullender/mullender.c</a></h3>
<h3 id="information-1984mullenderindex.html">Information: <a href="1984/mullender/index.html">1984/mullender/index.html</a></h3>
<p>Although there is an alt version and supplementary program added, that
will work in modern systems, if you do not have a
<a href="https://en.wikipedia.org/wiki/VAX-11">VAX-11</a> or
<a href="https://en.wikipedia.org/wiki/PDP-11">PDP-11</a> to run the original entry on it
will not work. See the index.html for details on the alternate versions.</p>
<p>The file <a href="https://github.com/ioccc-src/winner/blob/master/1984/mullender/gentab.c">gentab.c</a> which is from the
author’s (or one of them, Mullender) remarks, was fixed for modern systems, at
least as best as can be determined: running the code on the binary itself does
produce a <code>short[]</code> that can compile in modern systems but it will not work.
Before the fix it would fail in some cases and it is possible that in some cases
it might still fail.</p>
<p>Jump to: <a href="#">top</a></p>
<hr style="width:10%;text-align:left;margin-left:0">
<div id="1985">
<h1 id="section-1">1985</h1>
</div>
<hr style="width:10%;text-align:left;margin-left:0">
<p>There are no known bugs or (mis)features for entries in 1985.</p>
<p>Jump to: <a href="#">top</a></p>
<hr style="width:10%;text-align:left;margin-left:0">
<div id="1986">
<h1 id="section-2">1986</h1>
</div>
<hr style="width:10%;text-align:left;margin-left:0">
<p>Jump to: <a href="#">top</a></p>
<div id="1986_august">
<h2 id="august">1986/august</h2>
</div>
<p>Jump to: <a href="#">top</a></p>
<h3 id="status-inabiaf---please-do-not-fix-4">STATUS: INABIAF - please <strong>DO NOT</strong> fix</h3>
<h3 id="source-code-1986augustaugust.c">Source code: <a href="https://github.com/ioccc-src/winner/blob/master/1986/august/august.c">1986/august/august.c</a></h3>
<h3 id="information-1986augustindex.html">Information: <a href="1986/august/index.html">1986/august/index.html</a></h3>
<p>This entry is known to segfault after printing its output. It was documented by
the judges and shouldn’t be fixed.</p>
<p>Jump to: <a href="#">top</a></p>
<hr style="width:10%;text-align:left;margin-left:0">
<div id="1987">
<h1 id="section-3">1987</h1>
</div>
<hr style="width:10%;text-align:left;margin-left:0">
<p>There are no known bugs or (mis)features for entries in 1987.</p>
<p>Jump to: <a href="#">top</a></p>
<hr style="width:10%;text-align:left;margin-left:0">
<div id="1988">
<h1 id="section-4">1988</h1>
</div>
<hr style="width:10%;text-align:left;margin-left:0">
<p>Jump to: <a href="#">top</a></p>
<div id="1988_dale">
<h2 id="dale">1988/dale</h2>
</div>
<p>Jump to: <a href="#">top</a></p>
<h3 id="status-inabiaf---please-do-not-fix-5">STATUS: INABIAF - please <strong>DO NOT</strong> fix</h3>
<h3 id="source-code-1988daledale.c">Source code: <a href="https://github.com/ioccc-src/winner/blob/master/1988/dale/dale.c">1988/dale/dale.c</a></h3>
<h3 id="information-1988daleindex.html">Information: <a href="1988/dale/index.html">1988/dale/index.html</a></h3>
<p>In linux it might happen that despite no error message or message about doing
so, the program drops a core file into the directory even though the entry works
and does not crash.</p>
<p>Jump to: <a href="#">top</a></p>
<hr style="width:10%;text-align:left;margin-left:0">
<div id="1989">
<h1 id="section-5">1989</h1>
</div>
<hr style="width:10%;text-align:left;margin-left:0">
<p>Jump to: <a href="#">top</a></p>
<div id="1989_fubar">
<h2 id="fubar">1989/fubar</h2>
</div>
<p>Jump to: <a href="#">top</a></p>
<h3 id="status-inabiaf---please-do-not-fix-6">STATUS: INABIAF - please <strong>DO NOT</strong> fix</h3>
<h3 id="source-code-1989fubarfubar.c">Source code: <a href="https://github.com/ioccc-src/winner/blob/master/1989/fubar/fubar.c">1989/fubar/fubar.c</a></h3>
<h3 id="information-1989fubarindex.html">Information: <a href="1989/fubar/index.html">1989/fubar/index.html</a></h3>
<p>If you use either <code>fubar</code> or <code>ouroboros.c</code> (it’s executable, see index.html for
details) with a number < 0 or larger than, say 20, it’s very likely that the
program will turn into an infinite loop trying to compile code and end up with
with syntax errors. As this was documented it is not a bug to be fixed.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="1989_robison">
<h2 id="robison">1989/robison</h2>
</div>
<p>Jump to: <a href="#">top</a></p>
<h3 id="status-inabiaf---please-do-not-fix-7">STATUS: INABIAF - please <strong>DO NOT</strong> fix</h3>
<h3 id="source-code-1989robisonrobison.c">Source code: <a href="https://github.com/ioccc-src/winner/blob/master/1989/robison/robison.c">1989/robison/robison.c</a></h3>
<h3 id="information-1989robisonindex.html">Information: <a href="1989/robison/index.html">1989/robison/index.html</a></h3>
<p>This program will very likely crash or break into tiny bits :-) if you feed it
numbers with non-binary digits.</p>
<p>There are also other cases where this can happen for instance using unsupported
operators like <code>/</code>. To see what operators are supported check the source code.</p>
<p>Jump to: <a href="#">top</a></p>
<div id="1989_westley">
<h2 id="westley">1989/westley</h2>
</div>
<p>Jump to: <a href="#">top</a></p>
<h3 id="status-known-bug---please-help-us-fix">STATUS: known bug - please help us fix</h3>
<h3 id="source-code-1989westleywestley.c">Source code: <a href="https://github.com/ioccc-src/winner/blob/master/1989/westley/westley.c">1989/westley/westley.c</a></h3>
<h3 id="information-1989westleyindex.html">Information: <a href="1989/westley/index.html">1989/westley/index.html</a></h3>
<p>With version 2 it sometimes segfaults even with the same input where other times
it does not. We don’t believe this is because of the fix that lets some versions
be compiled with clang. An example invocation is:</p>
<pre><code> ./ver2 < westley.c</code></pre>
<p>Jump to: <a href="#">top</a></p>
<h3 id="a-useful-note-on-changingfixing-this-program">A useful note on changing/fixing this program</h3>
<p>It should be noted that in additional to rot13 names there is code that is the
reverse of other code (also with respect to names). See the source file and the
index.html (in the author’s remarks) for more details.</p>
<p>Fixing the (mis)feature is likely to be a very difficult challenge especially
without breaking something else which is far more likely (see below tips from).
You are welcome to try and fix it if you can but unless you can get all to
compile with <code>clang</code> <strong>AND</strong> <code>gcc</code>, which seems unlikely (see below), this
should not be touched further. Nonetheless you are welcome to try and fix it if
you can.</p>
<p>Be aware, however, that even if you can get it to compile with both <code>gcc</code> and
<code>clang</code>, different versions will have errors so that it’s not actually a fix.
For instance it was fixed to work for both <code>clang</code> and <code>gcc</code> but when testing
the fix in fedora linux it failed to even compile!</p>
<p>Jump to: <a href="#">top</a></p>
<h3 id="tips">Tips:</h3>
<p>The reason this is crashing is that the array <code>irk</code> is being accessed way out of
bounds by the int <code>gnat</code>. For instance:</p>
<pre><code> Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000401335 in main (ABBA@entry=<optimized out>, tang@entry=<optimized out>, gnat@entry=<optimized out>, Near@entry=<optimized out>)
at ver2.c:23
23 &&gnat!({)Near,noon,/*krelc*/)<0&&(Near= - irk[-gnat--]-2)))&&main(ABBA,
(gdb) p gnat
$1 = -518733305</code></pre>
<p>Jump to: <a href="#">top</a></p>
<h3 id="magic-of-the-entry">Magic of the entry:</h3>
<p>The real trouble is that the code is generated and in a complex way or rather
ways.</p>
<p>Trying to explain this might be tricky but here is an attempt. The program, when
used without any args, will print out what it reads. If one arg is specified it
will do a ROT13 of it. If two args are specified it will print out the text
backwards (<em>WITHOUT ROT13!</em>). If three args are specified it will do both
<strong><em>reversal AND ROT13</em></strong>.</p>
<p>So <code>ver0</code> is the same as the main program; <code>ver1</code> is the ROT13 of the code (but
see below); <code>ver2</code> will reverse the code and <code>ver3</code> will both reverse and ROT13
the code. But it’s trickier than that as one might expect.</p>
<p>The comments are processed too. Furthermore it happens that the last line
becomes the first and the first line becomes the last! Now if you look at the
code you’ll see on the first line:</p>
<pre><code> /**//*/};)/**/pain(*//**/tang ,gnat/**//*/,ABBA~,0-0(avnz;)0-0,tang,raeN</code></pre>
<p>In <code>ver0</code> it’ll be the same but the others are more interesting.</p>
<p>In <code>ver1</code> you’ll see on the last line:</p>
<pre><code> cnva((vag)NOON&2/*//*\\**/,gnat,tang ,NOON/**//*/(niam/**/);}/*//**/</code></pre>
<p>and on the first line:</p>
<pre><code> /**//*/};)/**/cnva(*//**/gnat ,tang/**//*/,NOON~,0-0(niam;)0-0,gnat,enrA</code></pre>
<p>Observe that the ROT13 of <code>pain</code> is <code>cnva</code> and the ROT13 of <code>main</code> is <code>znva</code>.
The ROT13 of <code>NOON</code> is <code>ABBA</code>. <code>vag</code> is ROT13 of <code>int</code>, <code>gnat</code> and <code>tang</code> are
ROT13 of each other as well which is the reverse of the original (this is not
because it goes backwards (it doesn’t in this version) but because they are
ROT13 pairs!). <code>main</code> spelt backwards is <code>niam</code> and <code>pain</code> spelt backwards is
<code>niap</code>. Furthermore see the Makefile for other defines that had to be specified
and for <code>ver2</code> and <code>ver3</code> (that both work with gcc) one had to be undefined (search
for <code>CDEFINE</code> and <code>-U</code>). These details will be important momentarily.</p>
<p>As far as <code>NOON</code> and <code>ABBA</code> being ROT13 pairs, notice how <code>NOON</code> is not in the
original code but <code>ABBA</code> is; but in other versions it becomes <code>NOON</code> and they
also have <code>abba</code> which the original code does not!</p>
<p>Now notice how the <code>avnz</code> in the first line got changed to <code>niam</code>, its ROT13
value. Notice also how some of these are in comments!</p>
<p><code>main()</code> is in there somewhere and that had to be changed to call
<code>pain()</code> (see the <a href="thanks-for-help.html#1989_westley">thanks</a>
file (see the <em>1989/westley</em> section for details on how as this was
not as straight forward as it is for other entries) as well. Now
if you notice on that line you have in a comment <code>niam</code>. If you
were to change that to <code>niap</code> (pain backwards) that function would
end up as <code>pain()</code> in generated code! That’s assuming that it’s
just the reversal version, of course but ver1 is the ROT13 version.</p>
<p>These facts are bad enough but then you throw in the reverse of it without ROT13
and then another version that has the reversal <em>and</em> ROT13 then you can see it’s
nigh impossible to fix if not impossible.</p>
<p>The fix to get it to even compile with clang and then get the first two
(counting the original, <code>ver0</code>) to work was quite hard due to how the comments
in reverse and ROT13 of it all works together, especially allowing all versions
to compile with gcc. The only reason that it doesn’t work completely with clang
is the arg types of main() (see if you can figure out how the change of <code>main()</code>
in <code>westley.c</code> is not carried over to versions 2 and 3!); originally none of
them compiled with clang.</p>
<p>But it was possible to get the ROT13 code to compile with clang but the other
versions, reversed as well as ROT13 and reversed code, proved much more
problematic. It is now possible to compile (or maybe mostly compile) all versions with
clang but on another system and it had syntax errors.</p>
<p>Enjoy! :-)</p>
<p>Jump to: <a href="#">top</a></p>
<hr style="width:10%;text-align:left;margin-left:0">
<div id="1990">
<h1 id="section-6">1990</h1>
</div>
<hr style="width:10%;text-align:left;margin-left:0">
<p>Jump to: <a href="#">top</a></p>
<div id="1990_baruch">
<h2 id="baruch">1990/baruch</h2>
</div>
<p>Jump to: <a href="#">top</a></p>
<h3 id="status-inabiaf---please-do-not-fix-8">STATUS: INABIAF - please <strong>DO NOT</strong> fix</h3>
<h3 id="source-code-1990baruchbaruch.c">Source code: <a href="https://github.com/ioccc-src/winner/blob/master/1990/baruch/baruch.c">1990/baruch/baruch.c</a></h3>
<h3 id="information-1990baruchindex.html">Information: <a href="1990/baruch/index.html">1990/baruch/index.html</a></h3>
<p>A point worth considering is that as the number passed into the program gets
bigger the number of lines of output gets substantially larger and it takes much
more time and resources to run as well. For instance:</p>
<pre><code> $ for n in $(seq 1 18); do echo "$n"; echo "$n" | time "./baruch" | wc -l | sed -E -e 's/[[:space:]]//g'; done
1
3