Merge pull request #723 from xexyl/2001-herrmann2

Fix 2001/herrmann2 for 64-bit and 32-bit

2001/herrmann2/.gitignore

@@ -1,2 +1 @@
 herrmann2
-herrmann2.alt

2001/herrmann2/Makefile

@@ -114,8 +114,8 @@ OBJ= ${PROG}.o
 DATA= herrmann2.cup herrmann2.ioccc
 TARGET= ${PROG}
 #
-ALT_OBJ= ${PROG}.alt.o
+ALT_OBJ=
-ALT_TARGET= ${PROG}.alt
+ALT_TARGET=
 
 
 #################
@@ -130,7 +130,7 @@ all: data ${TARGET}
 	supernova deep_magic magic charon pluto
 
 ${PROG}: ${PROG}.c
-	${CC} ${CFLAGS} -m32 $< -o $@ ${LIBS}
+	${CC} ${CFLAGS} $< -o $@ ${LIBS}
 
 # alternative executable
 #

2001/herrmann2/README.md

@@ -1,9 +1,6 @@
 # Most eye-crossing
 
 Immanuel Herrmann  
-University of Freiburg, Germany  
-Rehlingstr. 17  
-79100 Freiburg  
 Germany  
 <https://web.archive.org/web/20071018081145/http://pcpool.mathematik.uni-freiburg.de/~immi/>
 
@@ -14,12 +11,11 @@ make
 ```
 
 [Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) fixed this to work with
-clang by changing the args to main() to be `int` and `char **` respectively and
+both 64-bit and 32-bit compiles by changing most of the `int`s (all but that in
-changing specific references to the `argv` arg, casting to int which was its old
+`main`) to `long`s. He also fixed it to compile with clang by changing the args
-type. However this entry only works completely if compiled as 32-bit (it does
+of main to be `int` and `char **` respectively and changing specific references
-work in part if compiled as 64-bit). See the alternate code below for
+to the `argv` arg, casting to `long` (was `int` but the 64-bit fix requires
-information on the 64-bit version and [bugs.md](/bugs.md) for more details on
+`long`) which was its old type. Thank you Cody for your assistance!
-this issue in general. Thank you Cody for your assistance!
 
 
 ## To run:
@@ -28,20 +24,6 @@ this issue in general. Thank you Cody for your assistance!
 ./herrmann2
 ```
 
-
-### Alternate code:
-
-As noted above an alternate version is available for 64-bit. This will crash in
-some of the invocations given by the author but it will work for the basic
-operations. To use try:
-
-```sh
-make alt
-```
-
-Use `herrmann2.alt` as you would `herrmann2` above and below.
-
-
 ## Try:
 
 ```sh

2001/herrmann2/herrmann2.c

@@ -1,7 +1,7 @@
 char*d,A[9876];char*d,A[9876];char*d,A[9876];char*d,A[9876];char*d,A[9876];char
 e;b;*ad,a,c;  te;b;*ad,a,c;  te;*ad,a,c;  w,te;*ad,a,  w,te;*ad,and,  w,te;*ad,
 r,T; wri; ;*h; r,T; wri; ;*h; r; wri; ;*h;_, r; wri;*h;_, r; wri;*har;_, r; wri
-;on;l;i(int V);on;l;i(int V);o;l;mai(int n,int V);o;mai(int n,int V);main(int n,char**V)    
+;on;l;i(long V);on;l;i(long V);o;l;mai(long n,long V);o;mai(long n,long V);main(int n,char**V)    
    {-!har  ;      {-!har  ;      {har  =A;      {h  =A;ad        =A;read       
 (0,&e,o||n -- +(0,&e,o||n -- +(0,&o||n ,o-- +(0,&on ,o-4,- +(0,n ,o-=94,- +(0,n
 ,l=b=8,!( te-*A,l=b=8,!( te-*A,l=b,!( time-*A,l=b, time)|-*A,l= time(0)|-*A,l= 
@@ -10,7 +10,7 @@ r,T; wri; ;*h; r,T; wri; ;*h; r; wri; ;*h;_, r; wri;*h;_, r; wri;*har;_, r; wri
 )=+ +95>e?(*& c)=+ +95>e?(*& c) +95>e?(*& _*c) +95>(*& _*c) +95>(*&r= _*c) +95>
 5,r+e-r +_:2-195,r+e-r +_:2-195+e-r +_:2-1<-95+e-r +_-1<-95+e-r ++?_-1<-95+e-r 
 |(d==d),!n ?*d||(d==d),!n ?*d||(d==d),!n ?*d||(d==d),!n ?*d||(d==d),!n ?*d||(d=
- *( (char**)+(int)V+ *( (char)+(int)V+ *( (c),har)+V+  (c),har)+ (V+  (c),r)+ (V+  (  c),
+ *( (char**)+(long)V+ *( (char)+(long)V+ *( (c),har)+V+  (c),har)+ (V+  (c),r)+ (V+  (  c),
 +0,*d-7 ) -r+8)+0,*d-7 -r+8)+0,*d-c:7 -r+80,*d-c:7 -r+7:80,*d-7 -r+7:80,*d++-7 
 +7+! r: and%9- +7+! rand%9-85 +7+! rand%95 +7+!!  rand%95 +7+  rand()%95 +7+  r
 -(r+o):(+w,_+ A-(r+o)+w,_+*( A-(r+o)+w,_+ A-(r=e+o)+w,_+ A-(r+o)+wri,_+ A-(r+o)

bugs.md

@@ -1177,216 +1177,6 @@ animation but this does not seem to work with modern gcc versions. It appears
 that version 2.95 works but maybe others do as well. Do you have a fix? We would
 appreciate your help!
 
-## [2001/herrmann2](2001/herrmann2/herrmann2.c) ([README.md](2001/herrmann2/README.md)
-## STATUS: doesn't work with some platforms - please help us fix
-
-The basic operation of this program does work but when using the more advanced
-features it crashes but only if not compiled with `-m32`. This means that macOS
-cannot easily compile it - if it can at all; Apple makes it very hard to do so.
-To at least somewhat use it under macOS or a place where `-m32` is not possible
-try using the [2001/herrmann2/herrmann2-64.c](2001/herrmann2/herrmann2-64.c)
-program. The below describes the original including a fix for clang which does
-not include a fix for 64-bit but still works with clang with one caveat which is
-also described below.
-
-With the default [herrmann2.c](2001/herrmann2/herrmann2.c) the below invocations
-work fine - again as long as `-m32` works.
-
-
-```sh
-./herrmann2 \
-'char*d,A[9876];e;b;*ad,a,c;  tw,ndr,T; wri; ;*h; _,ar  ;on;'\
-' ;l ;i(V)man,n    {-!har  ;   =Aadre(0,&e,o||n -- +,o4,=9,l=b=8,'\
-'!( te-*Aim)|(0~l),srand  (l),,!A,d=,b))&&+((A + te-A(&(*)=+ +95>'\
-'e?(*& c_*r=5,r+e-r +_:2-19<-+?|(d==d),!n ?*d| *( (char**)+V+), ('\
-'  +0,*d-7 ) -r+8)c:7:+++7+! r: and%9- 85! ()-(r+o):(+w,_+ A*(=er'\
-'i+(o)+b)),!write,(=_((-b+*h)(1,A+b,!!((((-+, a >T^l,( o-95=+))w?'\
-'++  &&r:b<<2+a +w) ((!main(n*n,V) , +-) ),l)),w= +T-->o +o+;{ &!'\
-'a;}return _+= ' < herrmann2.ioccc
-```
-
-Note that with this it generates the original source code _prior to the clang
-fix_! This is a nice way to get the original prefixed version!
-
-This also works with 32-bit:
-
-```sh
-./herrmann2 "234 84 045 5 6765 7487 65190 84 656 254 12 43931 818 0 6542 \
-341 45 567 76967 7244 606 976567 895 81898 095 68678 1843 4650547 \
-565980691 389 04974" < herrmann2.ioccc
-```
-
-On the other hand these work with 64 bit (`Mach` or `x86_64`):
-
-```sh
-./herrmann2 < herrmann2.ioccc
-./herrmann2 < herrmann2.cup
-```
-
-A few notes from Cody:
-
-- The author stated that there are some layout restrictions and the changes made
-to get it to compile with clang might have impacted this some. However given
-that it appears to function correctly as long as it is compiled as a 32-bit
-binary both before and after the fix this is probably not relevant.
-- The author said that to add a function call one has to 'fill an entire line
-with stuff doing mostly nothing' but it was not specified what an entire line is
-nor what will happen otherwise. This is seen throughout the code and is likely
-the source of dead code and variable declarations being repeated.
-- At one point (not originally) my fix involved calling another function this
-was done to try and find more about the crash. However this caused the program
-to crash with the invocations that work as long as it's compiled with 32-bit so
-this has been rolled back. This might be due to the restrictions noted in this
-item and the above one but I'm not sure.
-- The entry will give different output each invocation! But what you'll see is that
-each line has a repeating pattern! This is expected.  See below for an example
-few lines.
-- There are some multiple and unsequenced modifications to some variables. See
-below for these. This again does not seem to matter in 32-bit - at least
-theoretically.
-- See below for possible crash locations when compiled as 64-bit.
-
-
-The remaining unsequenced modification warnings are:
-
-```
-herrmann2.c:6:12: warning: multiple unsequenced modifications to 'n' [-Wunsequenced]
-(0,&e,o||n -- +(0,&e,o||n -- +(0,&o||n ,o-- +(0,&on ,o-4,- +(0,n ,o-=94,- +(0,n
-           ^              ~~
-herrmann2.c:6:42: warning: unsequenced modification and access to 'o' [-Wunsequenced]
-(0,&e,o||n -- +(0,&e,o||n -- +(0,&o||n ,o-- +(0,&on ,o-4,- +(0,n ,o-=94,- +(0,n
-                                         ^           ~
-herrmann2.c:11:65: warning: unsequenced modification and access to 'r' [-Wunsequenced]
-5,r+e-r +_:2-195,r+e-r +_:2-195+e-r +_:2-1<-95+e-r +_-1<-95+e-r ++?_-1<-95+e-r
-                                                 ~              ^
-herrmann2.c:18:68: warning: unsequenced modification and access to 'b' [-Wunsequenced]
--b+*h)(1,A+b,!!-b+*h),A+b,((!!-b+*h),A+b,!!-b+((*h),A+b,!!-b+*h),A-++b,!!-b+*h)
-                                                                   ^
-```
-
-```
-6ejZR}DU}*u?CI)6ejZR}DU}*u?CI)6ejZR}DU}*u?CI)6ejZR}DU}*u?CI)6ejZR}DU}*u?CI)6ejZ
-```
-
-If you break it up you get:
-
-```
-6ejZR}DU}*u?CI)
-6ejZR}DU}*u?CI)
-6ejZR}DU}*u?CI)
-6ejZR}DU}*u?CI)
-6ejZR}DU}*u?CI)
-6ejZ
-```
-
-which you can see is quite similar.
-
-As for crash locations:
-
-```
-Program terminated with signal SIGSEGV, Segmentation fault.
-#0  main (n@entry=<optimized out>, V@entry=<optimized out>) at herrmann2.c:22
-22	     )+0,
-[...]
-```
-
-Note that that's not a `+` and the letter O; it's a zero!
-
-Since I broke the line down here's what the line looks like correctly:
-
-```c
-+0,*d-7 ) -r+8)+0,*d-7 -r+8)+0,*d-c:7 -r+80,*d-c:7 -r+7:80,*d-7 -r+7:80,*d++-7
-```
-
-What happens if we remove the `+0`? We then get on line 13:
-
-```
-*( (char**)+(int)V+ *( (char)+(int)V+ *( (c),har)+V+  (c),har)+ (V+  (c),r)+ (V+  (  c),
-
-```
-
-Breaking this line down and we see it's still line 13:
-
-```
-13	 *
-14	 ( (char**)+
-15	   (int)V+
-16	   *( (char)+
-17	       (int)V+
-```
-
-So let's merge the lines a bit:
-
-```
-#0  main (n@entry=<optimized out>, V@entry=<optimized out>) at herrmann2.c:13
-13	 *( (char**)+(int)V+
-(gdb) bt
-#0  main (n@entry=<optimized out>, V@entry=<optimized out>) at herrmann2.c:13
-(gdb) p (char**)+(int)V
-$1 = (char **) 0xffffffff831602d8
-(gdb) p *(char**)+(int)V
-Cannot access memory at address 0xffffffff831602d8
-```
-
-Still line 13. Let's do it again:
-
-```
-#0  0x0000000000401442 in main (n@entry=<optimized out>, V@entry=<optimized out>) at herrmann2.c:13
-13	 *( (char**)+(int)V+ *( (char)+ (int)V+ *( (c), har)+ V+ (c), har)+ (V+ (c), r)+ (V+ (  c), + 0, *d - 7 ) -r +8),
-(gdb) p *(( (char**)+(int)V+ *( (char)+ (int)V+ *( (c), har)+ V+ (c), har)+ (V+ (c), r)+ (V+ (  c), + 0, *d - 7 ) -r +8))
-Cannot access memory at address 0xffffffffbfa05960
-(gdb) p *( ( char**)+(int)V)
-Cannot access memory at address 0xffffffffbfa05958
-(gdb) p *( ( char**)+(int)V)+*((char)+(int)V)
-Cannot access memory at address 0x58
-(gdb) p *( (char)+ (int)V )
-Cannot access memory at address 0x58
-(gdb) p (int)V+*((c),har)
-$1 = -1080010408
-(gdb) ptype (int)V+*((c),har)
-type = int
-(gdb) p V
-$2 = (char **) 0x7fffbfa05958
-(gdb) p (int)V
-$3 = -1080010408
-(gdb) ptype V
-type = char **
-(gdb) p *V
-$4 = 0x7fffbfa07323 "./herrmann2"
-(gdb) ptype (int)V
-type = int
-(gdb) q
-
-```
-
-and so on. Note that with the fix for clang `V` is a `char **` not an int hence
-the casts. But is this relevant? Let's find out:
-
-```
-#0  0x0000000000401440 in main (n@entry=<optimized out>, V@entry=<optimized out>) at herrmann2.c:14
-14	+0,*d-7 ) -r+8)+0,*d-7 -r+8)+0,*d-c:7 -r+80,*d-c:7 -r+7:80,*d-7 -r+7:80,*d++-7
-```
-
-Now it's a different line! Can we fix this?
-
-```
-#0  main (n@entry=<optimized out>, V@entry=<optimized out>) at herrmann2.c:21
-21	 +0,
-```
-
-Again `+0`! Let's remove it:
-
-```
-#0  main (n@entry=<optimized out>, V@entry=<optimized out>) at herrmann2.c:13
-13	 *( (char**)+V+ *( (char)+V+ *( (c),har)+V+  (c),har)+ (V+  (c),r)+ (V+  (  c),
-(gdb) p *( (char **)V)
-Cannot access memory at address 0x544777d8
-```
-
-So now it's back to the same problem which means that it's most likely not
-because of the fix for clang. Still if you have a 32-bit compiler/linker you can
-run the program; else you can at least run the alt version that works in part.
-
 Do you have a fix for 64-bit compilation? Please provide it!
 ## [2001/kev](2001/kev/kev.c) ([README.md](2001/kev/README.md)
 ## STATUS: INABIAF - please **DO NOT** fix