Add alt code to 1986/hague - fgets()

The reason it is in alt code is because one of the forms of input (see
below) will, although print out correct output, segfault after
outputting the text. That is when one does something like:

    echo foo | ./hague.alt

Whether it might be worth making it the entry itself with a note in the
Makefile and README.md and bugs.md (because it does print out correct
output) can be determined later - or not.

This change required several files to be updated besides the new file
hague.alt.c.

1986/hague/.gitignore

@@ -1,3 +1,4 @@
 hague
+hague.alt
 hague.orig
 prog.orig

1986/hague/Makefile

@@ -114,8 +114,8 @@ OBJ= ${PROG}.o
 DATA=
 TARGET= ${PROG}
 #
-ALT_OBJ=
-ALT_TARGET=
+ALT_OBJ= ${PROG}.alt.o
+ALT_TARGET= ${PROG}.alt
 
 
 #################

1986/hague/README.md

@@ -9,9 +9,9 @@ UK
 make all
 ```
 
-
-NOTE: this entry uses `gets()` so you might get a warning about this when
-compiling and running this program with some systems.
+There is an alternate version which uses `fgets()`. See the Alternate code
+section below as well as the [bugs.md](/bugs.md) file for more details as to why
+it is worth having as an alternate version.
 
 ## To run:
 
@@ -29,6 +29,30 @@ International Obfuscated C Code Contest
 Jim Hague
 ```
 
+Also try:
+
+```sh
+echo IOCCC | ./hague
+```
+
+### Alternate code:
+
+Whereas with some entries the change to `fgets()` (see the [FAQ](/faq.md) for
+details on why this has been done) can be done in the original code this entry
+is more complicated in that although both forms of input show the correct
+output, one form segfaults after the output.
+
+If you wish to use this alternate code, do:
+
+```sh
+make alt
+```
+
+Use `hague.alt` as you would `hague` above. As for which form will segfault
+after outputting the text it is when text is piped into the program. Again see
+the [bugs.md](/bugs.md) file for more details.
+
+
 
 ## Judges' remarks:
 

1986/hague/hague.alt.c

@@ -0,0 +1,28 @@
+#define	DIT	(
+#define	DAH	)
+#define	__DAH	++
+#define DITDAH	*
+#define	DAHDIT	for
+#define	DIT_DAH	malloc
+#define DAH_DIT	fgets
+#define	_DAHDIT	char
+_DAHDIT _DAH_[]="ETIANMSURWDKGOHVFaLaPJBXCYZQb54a3d2f16g7c8a90l?e'b.s;i,d:"
+;main			DIT			DAH{_DAHDIT
+DITDAH			_DIT,DITDAH		DAH_,DITDAH DIT_,
+DITDAH			_DIT_,DITDAH		DIT_DAH DIT
+DAH,DITDAH		DAH_DIT DIT		DAH;DAHDIT
+DIT _DIT=DIT_DAH	DIT 81			DAH,DIT_=_DIT
+__DAH;_DIT=DAH_DIT	DIT _DIT,81,stdin	DAH,_DIT[strlen(_DIT)-1]='\0',_DIT!=NULL;__DIT
+DIT'\n'DAH DAH		DAHDIT DIT		DAH_=_DIT;DITDAH
+DAH_;__DIT		DIT			DITDAH
+_DIT_?_DAH DIT		DITDAH			DIT_ DAH:'?'DAH,__DIT
+DIT' 'DAH,DAH_ __DAH	DAH DAHDIT		DIT
+DITDAH			DIT_=2,_DIT_=_DAH_;	DITDAH _DIT_&&DIT
+DITDAH _DIT_!=DIT	DITDAH DAH_>='a'?	DITDAH
+DAH_&223:DITDAH		DAH_ DAH DAH;		DIT
+DITDAH			DIT_ DAH __DAH,_DIT_	__DAH DAH
+DITDAH DIT_+=		DIT DITDAH _DIT_>='a'?	DITDAH _DIT_-'a':0
+DAH;}_DAH DIT DIT_	DAH{			__DIT DIT
+DIT_>3?_DAH		DIT			 DIT_>>1 DAH:'\0'DAH;return
+DIT_&1?'-':'.';}__DIT DIT			DIT_ DAH _DAHDIT
+DIT_;{DIT void DAH write DIT			1,&DIT_,1 DAH;}

1986/hague/hague.c

@@ -4,7 +4,7 @@
 #define DITDAH	*
 #define	DAHDIT	for
 #define	DIT_DAH	malloc
-#define DAH_DIT	gets
+#define DAH_DIT	fgets
 #define	_DAHDIT	char
 _DAHDIT _DAH_[]="ETIANMSURWDKGOHVFaLaPJBXCYZQb54a3d2f16g7c8a90l?e'b.s;i,d:"
 ;main			DIT			DAH{_DAHDIT
@@ -12,7 +12,7 @@ DITDAH			_DIT,DITDAH		DAH_,DITDAH DIT_,
 DITDAH			_DIT_,DITDAH		DIT_DAH DIT
 DAH,DITDAH		DAH_DIT DIT		DAH;DAHDIT
 DIT _DIT=DIT_DAH	DIT 81			DAH,DIT_=_DIT
-__DAH;_DIT==DAH_DIT	DIT _DIT		DAH;__DIT
+__DAH;_DIT=DAH_DIT	DIT _DIT,81,stdin	DAH,_DIT[strlen(_DIT)-1]='\0',_DIT!=NULL;__DIT
 DIT'\n'DAH DAH		DAHDIT DIT		DAH_=_DIT;DITDAH
 DAH_;__DIT		DIT			DITDAH
 _DIT_?_DAH DIT		DITDAH			DIT_ DAH:'?'DAH,__DIT

bugs.md

@@ -469,11 +469,27 @@ the judges and shouldn't be fixed.
 This entry uses `gets()` which is unsafe. In particular the buffer size is a
 mere 81 and it does not read a single string at command invocation but instead
 until the program is terminated. This size can be increased to start out but it
-would be better if it used `fgets()`. This will be addressed in time but is
-noted here as a reminder.
+would be better if it used `fgets()`.
 
 The way this entry is formed has made it not as simple as some of the others
-that have been addressed.
+that have been addressed at least in part. It is easy to get it to use `fgets()`
+and this has been done in the [alternate code](1986/hague/hague.alt.c) but it
+will segfault after outputting the (correct) text in one of the forms. In
+particular whereas this:
+
+```sh
+./hague.alt
+foo
+
+works the following will print out the correct output but then segfault:
+
+```
+```sh
+echo foo | ./hague.alt
+```
+
+Whether or not it is worth making the entry itself (since the output is correct)
+this alt version is to be determined later but it's might very well not be.
 
 
 ## [1986/holloway](1986/holloway/holloway.c) ([README.md](1986/holloway/README.md))

faq.md

@@ -88,6 +88,30 @@ some entries you should look at the original code as in `winner.orig.c` or
 `prog.orig.c`. Sometimes the original is in an alt version like `winner.alt.c`
 or `prog.alt.c`.
 
+## Q: Why have some entries that originally used `gets()` been modified to use `fgets()`? Doesn't this tamper with the entry too much?
+
+A fine line indeed has to be drawn here but it was decided that it is worth it
+because of alarming warnings that can be displayed, in some systems at runtime
+interspersed with the output of the program.
+
+For instance in macOS the entry [1990/tbr](1990/tbr/README.md) would output the
+warning in such a way that caused confusing output for the entry.
+
+In some cases this is not so easy to fix and in one case at least there is an
+alternate version that has the fix instead due to a problem it creates (correct
+output but segfaults after the output in one of the forms of input).
+
+In some cases it is not possible to fix or at least highly unlikely and so those
+have mainly not been touched except one that has had the buffer size increased
+(which could be done for others that are not possible to change to `fgets()` but
+this has not been done).
+
+In the future we, the judges, would prefer that entries use `fgets()` to prevent
+these problems.
+
+NOTE: due to 'compatibility reasons' `fgets()` stores the newline and `gets()`
+does not. We're not sure how this is compatibility but either way it can cause a
+problem and it is this that has complicated some fixes.
 
 ## Q: I cannot get entry XYZZY from year 19xx to compile!
 

thanks-for-fixes.md

@@ -138,6 +138,17 @@ entry which can be found in
 [1985/sicherman/sicherman.orig.c](1985/sicherman/sicherman.orig.c).
 
 
+## [1986/hague](1986/hague/hague.c) ([README.md](1986/hague/README.md]))
+
+Cody added alt code that uses `fgets()` to avoid alarming and annoying warnings
+about `gets()` being unsafe. The reason this is alt code, at least for now, is
+that although it will print the results in both forms of invocation, after the
+output in one invocation form it will segfault. This might be addressed later on
+or it might be decided that it is worth it, with a caveat in the Makefile or at
+least the README.md file, since it still prints out the correct output, though
+that seems like it might not be so ideal unless it can be fixed (which might be
+done). See the [bugs.md](/bugs.md) file for details.
+
 ## [1986/holloway](1986/holloway/holloway.c) ([README.md](1986/holloway/README.md]))
 
 Cody fixed this to compile and work with clang (it already worked with gcc).