Fix 2001/herrmann2 for 64-bit and 32-bit
By chance I looked at this entry again and it immediately popped into my head how to get it to work. Except for the one in main() the ints need to be longs. This will now compile and work as expected both with 64-bit and 32-bit compilation. Disabled make alt and updated .gitignore.
This commit is contained in:
Cody Boone Ferguson committed
1 parent
104a8496e7
commit
1d54238e18
5 files changed
+10
-239
No files matched your search
@@ -1,2 +1 @@
|
||||
herrmann2
|
||||
herrmann2.alt
|
||||
@@ -114,8 +114,8 @@ OBJ= ${PROG}.o
|
||||
DATA= herrmann2.cup herrmann2.ioccc
|
||||
TARGET= ${PROG}
|
||||
#
|
||||
ALT_OBJ= ${PROG}.alt.o
|
||||
ALT_TARGET= ${PROG}.alt
|
||||
ALT_OBJ=
|
||||
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
|
||||
#
|
||||
|
||||
@@ -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
|
||||
changing specific references to the `argv` arg, casting to int which was its old
|
||||
type. However this entry only works completely if compiled as 32-bit (it does
|
||||
work in part if compiled as 64-bit). See the alternate code below for
|
||||
information on the 64-bit version and [bugs.md](/bugs.md) for more details on
|
||||
this issue in general. Thank you Cody for your assistance!
|
||||
both 64-bit and 32-bit compiles by changing most of the `int`s (all but that in
|
||||
`main`) to `long`s. He also fixed it to compile with clang by changing the args
|
||||
of main to be `int` and `char **` respectively and changing specific references
|
||||
to the `argv` arg, casting to `long` (was `int` but the 64-bit fix requires
|
||||
`long`) which was its old type. 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
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in new issue
Block a user