From c064d888f2660a72e4ea844f752e71e46e2ca5a2 Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Fri, 13 Oct 2023 06:38:17 -0700 Subject: [PATCH] Restore where possible macros in 2001/bellard When trying to get this entry to work for modern systems I ended up replacing some macros with what they translated to. This meant that it did not look as close to what the original entry looked like. There was another change as well in this commit. The variable that is the file to open was changed to a FILE * instead of an int. Although it did not crash after the change I made when trying to open the file (see below for why this was done) it's not strictly correct either in modern systems (and maybe not in older systems either though it clearly worked). Now as for why the fix to being able to open the file: it's because at the time I was trying to get it to work with modern systems even though the author stated that it was designed for i386 linux. Doing this proved possible with a number of other entries but in order for it to even get to that point this change was necessary. According to Yusuke Endoh, it did work with an emulator so that was not strictly necessary but I did not know this at the time and it seems better that at least it can open the file even if it won't completely work due to the way it is designed. It seems better too as it might help provide a way to get a version for 64-bit systems. The thanks-for-fixes.md and bugs.md files were updated on account of these changes. The bugs.md file also includes why it was changed when the entry is designed for i386 linux: besides the fact that I fixed the supplementary program that did not work at all. It seems that, according to Yusuke, that both works in an emulator but this way at least one can enjoy the supplementary program in modern systems too and the entry itself is a bit more correct. The bug status of this entry changed as well. It now has both INABIAF but also asking for alternate code. Why this is is explained in the file: it does indeed seem to not make sense but the rationale is explained there. --- 2001/bellard/Makefile | 4 +-- 2001/bellard/README.md | 3 -- 2001/bellard/bellard.c | 66 ++++++++++++++++++++++-------------------- bugs.md | 50 +++++++++++++++++++++++--------- thanks-for-fixes.md | 23 +++++++++------ 5 files changed, 86 insertions(+), 60 deletions(-) diff --git a/2001/bellard/Makefile b/2001/bellard/Makefile index e17c4d549..1a0c1bca3 100644 --- a/2001/bellard/Makefile +++ b/2001/bellard/Makefile @@ -132,9 +132,9 @@ all: data ${TARGET} supernova deep_magic magic charon pluto ${PROG}: ${PROG}.c - @echo "WARNING: ${PROG}.c must be compiled as 32-bit to use with the entry itself;" - @echo "if you cannot use -m32 this will NOT work!" ${CC} ${CFLAGS} -m32 $< -o $@ ${LDFLAGS} || : + @echo "WARNING: ${PROG}.c must be compiled as 32-bit to use with the entry itself:" + @echo "if you cannot use -m32 this will NOT work! This entry also requires i386 linux." ${PROG}.otccex: ${PROG}.otccex.c ${CC} ${CFLAGS} $< -o $@ ${LDFLAGS} diff --git a/2001/bellard/README.md b/2001/bellard/README.md index 7203ae8ce..7cf2b0b38 100644 --- a/2001/bellard/README.md +++ b/2001/bellard/README.md @@ -1,9 +1,6 @@ # Best abuse of the rules Fabrice Bellard -451 chemin du mas de Matour -34790 Grabels -France diff --git a/2001/bellard/bellard.c b/2001/bellard/bellard.c index 9871b95a2..7799fd23c 100644 --- a/2001/bellard/bellard.c +++ b/2001/bellard/bellard.c @@ -14,13 +14,15 @@ #define f () #define J return #define l ae( +#define n e) #define u d!= #define F int #define y (j) #define r m= #define t +4 -F d,z,C,h,P,K,ac,q,G,v,Q,R,D,L,W,M; -E(int e){ +F d,z,C,h,P,K,ac,q,G,v,R,D,L,W,M; +FILE *Q; +E(n{ x D++=e; } o f{ @@ -134,43 +136,43 @@ x q++=g; g=g>>8; } } -A(int e){ +A(n{ F g; -p e){ +p n{ g=k e; k e=q-e-4; e=g; } } -s(int g,int e){ +s(g,n{ l g); k q=e; e=q; q=q t; J e; } -H(e){ -s(184,e); +H(n{ +s(184,n; } -B(e){ -J s(233,e); +B(n{ +J s(233,n; } -S(int j,int e){ +S(j,n{ l 1032325); -J s(132+j,e); +J s(132+j,n; } -Z(int e){ +Z(n{ l 49465); H(0); l 15); l e+144); l 192); } -N(int j,int e){ +N(j,n{ l j+131); -s((e<512)<<7|5,e); +s((e<512)<<7|5,n; } -T (int j){ +T y{ F g,e,m,aa; g=1; a d b 34){ @@ -224,7 +226,7 @@ w f; l 89); l 392+(e b 256)); } -i a e){ +i a n{ a e b 256)l 139); i l 48655); q++; @@ -267,7 +269,7 @@ k r j; c; a!g){ e=e t; -k e=s(232,k e); +k e=s(232,k n; } i a g b 1){ s(2397439,j); @@ -279,11 +281,11 @@ s(232,g-q-5); a j)s(50305,j); } } -O (int j){ +O y{ F e,g,m; a j--b 1)T(1); i{ -O (j); +O y; r 0; p j b C){ g=d; @@ -291,17 +293,17 @@ e=z; c; a j>8){ r S(e,m); -O (j); +O y; } i{ l 80); -O (j); +O y; l 89); a j b 4|j b 5){ -Z(e); +Z(n; } i{ -l e); +l n; a g b 37)l 146); } } @@ -311,7 +313,7 @@ r S(e,m); H(e^1); B(5); A(m); -H(e); +H(n; } } } @@ -322,19 +324,19 @@ U f{ w f; J S(0,0); } -I (int j){ +I y{ F m,g,e; a d b 288){ c; c; r U f; c; -I (j); +I y; a d b 312){ c; g=B(0); A(m); -I (j); +I y; A(g); } i{ @@ -360,7 +362,7 @@ a u 41){ e=B(0); w f; B(g-q-5); -A(e); +A(n; g=e t; } } @@ -372,7 +374,7 @@ A(m); i a d b 123){ c; ab(1); -p u 125)I (j); +p u 125)I y; c; } i{ @@ -389,7 +391,7 @@ i a u 59)w f; c; } } -ab (int j){ +ab y{ F m; p d b 256|u-1&!j){ a d b 256){ @@ -431,7 +433,7 @@ k r G; } } } -int main(int g,char **e){ +int main(int g, char **e){ Q=stdin; a g-->1){ *e=e[1]; @@ -444,6 +446,6 @@ P V; o f; c; ab(0); -J(*(int(*)f)k(P+592))(g,e); +J(*(int(*)f)k(P+592))(g,n; } diff --git a/bugs.md b/bugs.md index 5ca80223d..bc262de94 100644 --- a/bugs.md +++ b/bugs.md @@ -1139,14 +1139,24 @@ this program will very likely crash or do something strange like slaughter the elves of Imladris :-( ## [2001/bellard](2001/bellard/bellard.c) ([README.md](2001/bellard/README.md)) +## STATUS: INABIAF - please **DO NOT** fix ## STATUS: doesn't work with some platforms - please help us fix +The two statuses might seem contradictory but that is a complicated question. +The author stated that it only works with i386 linux so on the one hand the fact +it doesn't work in modern systems is considered a feature and not a bug. But on +the other hand it would be nice if there was an alternate version which worked +for modern systems. This does seem quite unlikely but some fixes, described +next, were made. + [Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) fixed an initial -segfault and he also fixed the [supplementary program -bellard.otccex.c](2001/bellard/bellard.otccex.c) but this still crashes. Below -are some notes about getting this entry to work but the gist of it is that it -requires i386 linux. Can you fix it for 64-bit linux? We welcome your help! Here -are some notes of interest: +segfault (trying to open the file) and he also fixed the [supplementary program +bellard.otccex.c](2001/bellard/bellard.otccex.c) but this still crashes in +systems not i386 linux which is what the author stated. + +On the other hand if you do have a fix for 64-bit systems you're welcome to +provide it as an alternate version. If by chance you have a fix so that it works +for both 32-bit and 64-bit systems that is also okay. The author said that they compiled it with [gcc version 2.95.2](https://ftp.gnu.org/gnu/gcc/gcc-2.95.2/gcc-everything-2.95.2.tar.gz). We @@ -1154,27 +1164,39 @@ don't know if a certain gcc version is necessary but it might be helpful to download and compile that version to test it - or it might not. I (Cody) have no i386 system to test this but perhaps this is why I can't get it -to work. Yusuke was able to get this to work with `-m32` but it seems with an +to work. Yusuke was able to get this to work with `-m32` but only in an emulator. -On the author's [web page for this program](https://bellard.org/otcc/) where it -is stated it requires i386 linux. +On the author's [web page for this program](https://bellard.org/otcc/) it is +explicitly stated that it requires i386 linux. There I found what should be a more portable version which is included as [otccelf.c](2001/bellard/otccelf.c) (after adding some `#include`s and the -modification by Yusuke noted in the README.md file) but it appears this also +modification by Yusuke noted in the README.md file) but it appears this *also* requires i386 linux; indeed looking at the code it hard codes paths that are i386 specific to linux. Another point of interest is that the author provided de-obfuscated versions which might be of value to look at. I might do that as well but this entry is -very likely never going to work for 64-bit linux. +very likely never going to work for 64-bit linux so that's not that likely since +there are other things that are more important. -Or maybe you have a fix for 64-bit CPUs? You might like to look at the otccelf -version but note that it at least in 64-bit linux (and macOS) have compilation -errors. +If you have a fix for 64-bit systems this is welcome as an alternate version, as +stated above. You might like to look at the otccelf version but note that it (at +least in 64-bit linux and macOS) has compilation errors. -Either way we welcome your help! Thank you! +### Aside: why were there changes if INABIAF ? + +This is a good question. The reason is we believe it better to fix some obvious +problems: there were some bugs that would very possibly prevent it from working +even if it was in i386 linux though Yusuke seemed to get it to work in an +emulator so perhaps not. Still it's better to have the type of the file pointer +correct and so that the file can at least be opened in modern systems even if +the compiler won't work there. + +Also the supplementary program, which did not work at all, was fixed (by Cody) +and it can be run by itself for fun in modern systems, which was not possible +before the fixes there. ## [2001/cheong](2001/cheong/cheong.c) ([README.md](2001/cheong/README.md)) diff --git a/thanks-for-fixes.md b/thanks-for-fixes.md index 20d18581d..f5bab1858 100644 --- a/thanks-for-fixes.md +++ b/thanks-for-fixes.md @@ -1084,19 +1084,24 @@ it will at least run the supplementary program as a 64-bit program directly. Cody fixed this to compile with clang but according to the author this will not work without i386 linux. It generates i386 32-bit code (not bytecode) but -unfortunately it will not work without i386 linux. Cody fixed an earlier -segfault so that it can at least now open the file and he also changed some of -the macros used to what they translate to but mostly it was kept the same. +unfortunately it will not work without i386 linux. See [bugs.md](/bugs.md). + +Cody fixed an earlier segfault so that it can at least now open the file should +you have an i386 linux machine (it can open it in other platforms too, of +course, but it won't work). This involved pointer updates and also changing an +`int` to a `FILE *`. Where possible he left the macros as the same but in the +case of `main()` this was not possible. + Yusuke added another change (see below) to make it even more portable across compilers besides what Cody did. - -Cody also fixed the [supplementary +Cody entirely fixed the [supplementary bellard.otccex.c](2001/bellard/bellard.otccex.c) so it does not segfault and -works as well. The main problem was that some ints were being used as pointers. -This includes, for example, an int used as a `char *`, an int used as a function -pointer and an int to access `argv` as well as there being invalid access to -`argv`. He updated the Makefile so that this program will compile by default. +works as well (it did not work at all). The main problem was that some ints were +being used as pointers. This includes, for example, an int used as a `char *`, +an int used as a function pointer and an int to access `argv` as well as there +being invalid access to `argv`. He updated the Makefile so that this program +will compile by default. Also the Fibonacci sequence (`fib()`) will overflow at `n > 48` so this is checked prior to running the function just like the author did for the factorial