Fix 2005/giljade to work with 64 and 32-bit
The problem was due to sizes so the long * is now an int *. I have no idea what made me think of it other than on a hunch (and based on my previous suspicions). Format fix README.md as well. Update bugs.md. Added an INABIAF as well as change the status of the program not working on some platforms to a known bug. This is to due with clang's deficiency in not allowing the args of main() to be different. Believe it or not some of the problem appears to be more than two spaces in the program (other than where it originally was). Added alt code - the original that will not compile with clang but with the 64-bit fix. This is because the fix for clang breaks the self-test feature of the program. Maybe the clang fix should be the alt code. I don't know. Updated .gitignore. Of course the above fix to the code and the adding of the alt code means that the Makefile was also updated.
This commit is contained in:
Cody Boone Ferguson committed
1 parent
5dc92c162d
commit
f7f0ca7500
6 files changed
+195
-86
No files matched your search
@@ -1 +1,4 @@
|
||||
giljade
|
||||
giljade.alt
|
||||
out
|
||||
c.c
|
||||
+10
-7
@@ -42,7 +42,8 @@ CSILENCE= -Wno-bitwise-conditional-parentheses -Wno-bitwise-op-parentheses \
|
||||
-Wno-builtin-requires-header -Wno-empty-body -Wno-error \
|
||||
-Wno-implicit-function-declaration -Wno-extra-semi -Wno-implicit-int \
|
||||
-Wno-logical-op-parentheses -Wno-return-type -Wno-shift-op-parentheses \
|
||||
-Wno-unused-value -Wno-incompatible-pointer-types -Wno-int-conversion
|
||||
-Wno-unused-value -Wno-incompatible-pointer-types -Wno-int-conversion \
|
||||
-Wno-parentheses -Wno-misleading-indentation
|
||||
|
||||
# Common C compiler warning flags
|
||||
#
|
||||
@@ -57,7 +58,7 @@ CSTD= -std=gnu99
|
||||
# Some entries require 32-bitness: ARCH= -m32
|
||||
# Some entries require 64-bitness: ARCH= -m64
|
||||
#
|
||||
ARCH= -m32
|
||||
ARCH=
|
||||
|
||||
# Defines that are needed to compile
|
||||
#
|
||||
@@ -65,7 +66,7 @@ CDEFINE=
|
||||
|
||||
# Include files that are needed to compile
|
||||
#
|
||||
CINCLUDE= -include stdio.h
|
||||
CINCLUDE= -include stdio.h -include string.h -include unistd.h -include stdlib.h
|
||||
|
||||
# Optimization
|
||||
#
|
||||
@@ -89,7 +90,7 @@ ifeq ($(CC),clang)
|
||||
#
|
||||
CSILENCE+= -Wno-comma -Wno-format-nonliteral -Wno-missing-prototypes \
|
||||
-Wno-missing-variable-declarations -Wno-poison-system-directories \
|
||||
-Wno-strict-prototypes
|
||||
-Wno-strict-prototypes -Wno-parentheses -Wno-misleading-indentation
|
||||
#
|
||||
CWARN+= -Weverything
|
||||
#
|
||||
@@ -117,8 +118,8 @@ OBJ= ${PROG}.o
|
||||
DATA=
|
||||
TARGET= ${PROG}
|
||||
#
|
||||
ALT_OBJ=
|
||||
ALT_TARGET=
|
||||
ALT_OBJ= ${PROG}.alt.o
|
||||
ALT_TARGET= ${PROG}.alt
|
||||
|
||||
|
||||
#################
|
||||
@@ -133,7 +134,6 @@ all: data ${TARGET}
|
||||
supernova deep_magic magic charon pluto
|
||||
|
||||
${PROG}: ${PROG}.c
|
||||
@echo "NOTE: this entry requires 32-bit architecture in order to run properly"
|
||||
${CC} ${CFLAGS} $< -o $@ ${LIBS}
|
||||
|
||||
# alternative executable
|
||||
@@ -141,6 +141,9 @@ ${PROG}: ${PROG}.c
|
||||
alt: data ${ALT_TARGET}
|
||||
@${TRUE}
|
||||
|
||||
${PROG}.alt: ${PROG}.alt.c
|
||||
${CC} ${CFLAGS} $< -o $@ ${LIBS}
|
||||
|
||||
# data files
|
||||
#
|
||||
data: ${DATA}
|
||||
|
||||
+82
-60
@@ -1,10 +1,10 @@
|
||||
# Best 2D puzzle
|
||||
|
||||
Gil Dogon
|
||||
1 HaBeer Alley
|
||||
Jerusalem
|
||||
Israel
|
||||
gil_jade@netvision.net.il
|
||||
Gil Dogon
|
||||
1 HaBeer Alley
|
||||
Jerusalem
|
||||
Israel
|
||||
<gil_jade@netvision.net.il>
|
||||
|
||||
## To build:
|
||||
|
||||
@@ -12,29 +12,37 @@ gil_jade@netvision.net.il
|
||||
make
|
||||
```
|
||||
|
||||
[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) discovered that there
|
||||
are two things that are needed in order to get this to work in modern systems.
|
||||
First it needs 32-bit architecture so the Makefile now has `-m32`. It appears
|
||||
it's because of the size of ints being different which affects the bitwise
|
||||
operations though this is just a hunch. Second is the optimiser cannot be
|
||||
enabled for this to work. Both changes made and it works. This does prove a
|
||||
problem for macOS as it no longer easily allows for compiling with 32-bit
|
||||
possibly even if you have the Intel chip (it certainly does not work with arm64
|
||||
macOS). It might be possible to get the entry to work with 64-bit by changing
|
||||
the int size but this is currently unknown. Thank you Cody for your help in
|
||||
getting this to work!
|
||||
|
||||
|
||||
## To run:
|
||||
|
||||
```sh
|
||||
./giljade
|
||||
```
|
||||
|
||||
[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) fixed this for modern
|
||||
systems. The problem that was showing up is that with either optimising or
|
||||
anything but 32-bit was used it would not work. The optimising cannot be used
|
||||
still but it now works with both 32-bit and 64-bit. The problem was the size of
|
||||
`int` and `long` being different now. Instead of `long *E` it is now `int *E`.
|
||||
This solves the problem for both 32-bit and 64-bit as long as optimising is
|
||||
disabled. Tested under linux (32-bit, 64-bit) and macOS (arm64). Thank you Cody
|
||||
for your assistance!
|
||||
|
||||
NOTE: the self-test feature no longer works due to the fix for clang (which
|
||||
requires the first arg of `main()` to be an `int` and the second arg to be `char
|
||||
**`). Believe it having more than two spaces in the code, except where the
|
||||
original code has them, appears to be part of the problem but it's not the full
|
||||
story. If you have a compiler that doesn't have this deficiency (e.g. gcc) you
|
||||
can use the alternate code described below.
|
||||
|
||||
### INABIAF - it's not a bug it's a feature! :-)
|
||||
|
||||
If the program source file is not lying in the same directory this program will
|
||||
very likely crash or do something strange.
|
||||
|
||||
## Try:
|
||||
|
||||
```sh
|
||||
giljade > out
|
||||
./giljade > out
|
||||
```
|
||||
Open an xterm with 78 lines.
|
||||
|
||||
@@ -44,13 +52,28 @@ vi out
|
||||
|
||||
Press ^F (control F) repeatedly.
|
||||
|
||||
### Alternate code:
|
||||
|
||||
Thanks to the fix for `clang` the self-test feature (of the output, see the
|
||||
author's remarks) does not work. If however you have gcc which does not have the
|
||||
defect that clang has with requirements in `main()`s args you can still use it
|
||||
via the alternate code. To compile:
|
||||
|
||||
|
||||
```sh
|
||||
make alt
|
||||
```
|
||||
|
||||
Use `giljade.alt` as you would `giljade`.
|
||||
|
||||
|
||||
## Judges' remarks:
|
||||
|
||||
This entry takes editorial in how it deals with its output. After using
|
||||
vi to look at the source, use vi to look at its output. We especially
|
||||
recommend it on a 78 column xterm while leaning on Control-F.
|
||||
|
||||
Do you really understand expressions, then understand this:
|
||||
If you really understand expressions, then understand this:
|
||||
|
||||
```c
|
||||
s=s^(b=s&s-1^s)
|
||||
@@ -65,8 +88,8 @@ s=s^(b=s&s-1^s)
|
||||
Just run the executable with no command line args and look at the output. In
|
||||
order to properly enjoy it you will need two good old programs: xterm and vi.
|
||||
Do the following: open an xterm with precisely 78 lines, and use the tiny font
|
||||
size for best results. Then vi (vim will also do) the output. Type ^F's and
|
||||
enjoy the show ...
|
||||
size for best results. Then vi (vim will also do) the output. Type `^F`
|
||||
repeatedly or hold it down and enjoy the show ...
|
||||
|
||||
The program solves (very very fast) a sliding block puzzle. There are many
|
||||
variants of such puzzles which are usually made from wood or plastic pieces.
|
||||
@@ -74,9 +97,9 @@ The start position can be recognized by looking at the program itself. The
|
||||
goal is to move the big piece (2 by 2) to the center top, which takes 179
|
||||
steps in the shortest move sequence.
|
||||
|
||||
Notice: the step count used by the program is longer than the traditional step
|
||||
count for such puzzles, as normally if the same piece is moved twice in a row
|
||||
it is counted as only one step, but here it is counted as two.
|
||||
Notice that the step count used by the program is longer than the traditional
|
||||
step count for such puzzles, as normally if the same piece is moved twice in a
|
||||
row it is counted as only one step, but here it is counted as two.
|
||||
|
||||
The printout of the solution however is in a rather unorthodox form, as can be
|
||||
easily discerned. As you have probably suspected each of the steps in the
|
||||
@@ -88,10 +111,10 @@ layouts. It is self-improving, in that the programs it prints have three
|
||||
advantages over the original:
|
||||
|
||||
1. Their layout is more precise (Notice the annoying \ at the 10'th line of
|
||||
the original program which is actually a 'layout bug'
|
||||
the original program which is actually a 'layout bug').
|
||||
|
||||
2. Their binary output does not rely on the source file being in the same
|
||||
directory, and will not dump core like the original if it doesn't. :)
|
||||
directory, and will not dump core if it doesn't (like the original does). :)
|
||||
|
||||
3. They have much more comments (Not very helpful ones though).
|
||||
|
||||
@@ -100,56 +123,55 @@ places, and checking that indeed the output is composed of 180 legal C
|
||||
programs by hand can be quite tedious, hence the program also include a self-
|
||||
test mode. Just run it with the output file as command line argument. It will
|
||||
then try to compile each of the programs (printing the line number where the
|
||||
program starts) It will stop where any compilation fails and the culprit
|
||||
program would be in the file 'c.c'. The exit code of the self-test will be
|
||||
program starts). It will stop where any compilation fails and the culprit
|
||||
program would be in the file `c.c`. The exit code of the self-test will be
|
||||
non-zero in that case. In case this entry wins, I do hope nobody by the name
|
||||
of 'c' also wins this year otherwise that part of the program would have to be
|
||||
changed!
|
||||
|
||||
Notice that the self-test does not try to run the result of the compilations
|
||||
but this can easily be done. try it and diff the output of any of the 180
|
||||
but this can easily be done. Try it and diff the output of any of the 180
|
||||
results with the original output. Of course all 180 programs also include the
|
||||
self-test mode.
|
||||
|
||||
### Why I think this program is obfuscated.
|
||||
|
||||
* Because its says so, and twice is better than once!
|
||||
* All the usual suspects i.e. ?: && || , used to compress code length in the
|
||||
noble tradition of this contest, meaningless one character variable names,
|
||||
etc...
|
||||
* The board representation is efficiently compressed hence obfuscated, and
|
||||
* Because it says so, and twice is better than once!
|
||||
* All the usual suspects i.e. `?:`, `&&`, `||`, `,` used to compress code
|
||||
length in the noble tradition of this contest, meaningless one character
|
||||
variable names, etc...
|
||||
* The board representation is efficiently compressed hence obfuscated, and
|
||||
the algorithm that is used to generate possible moves is extremely efficient.
|
||||
|
||||
In fact it can compute several moves in parallel on one processor! Moreover
|
||||
Only the most efficient bitwise logical operations, shift,and subtraction by
|
||||
one is used. No inefficient conditional tests and jumps are needed in that
|
||||
part of the program.
|
||||
|
||||
* The single expression I'm most proud of, and would have submitted to the
|
||||
In fact it can compute several moves in parallel on one processor! Moreover
|
||||
Only the most efficient bitwise logical operations, shift,and subtraction by
|
||||
one is used. No inefficient conditional tests and jumps are needed in that
|
||||
part of the program.
|
||||
* The single expression I'm most proud of, and would have submitted to the
|
||||
category of 'best obfuscated short expression' if there was one is:
|
||||
|
||||
s=s^(b=s&s-1^s)
|
||||
|
||||
Can you figure out what it does (very efficiently) and how it fits in the
|
||||
scheme of things?
|
||||
Can you figure out what it does (very efficiently) and how it fits in the
|
||||
scheme of things?
|
||||
|
||||
* IMHO the program is easier to understand before running cpp on it. It is
|
||||
also shorter that way to be sure.
|
||||
* It even takes care to obfuscate the comments in the output programs.
|
||||
* Having the output programs a bit different than the original is more
|
||||
* IMHO the program is easier to understand before running cpp on it. It is also
|
||||
shorter that way to be sure.
|
||||
* It even takes care to obfuscate the comments in the output programs.
|
||||
* Having the output programs a bit different than the original is more
|
||||
interesting.
|
||||
* I have written an earlier version of the program about half a year ago and
|
||||
when returning to it now I had to sweat quite a lot to understand the f***ing
|
||||
* I have written an earlier version of the program about half a year ago and
|
||||
when returning to it now I had to sweat quite a lot to understand the f\*\*\*ing
|
||||
mess I've made.
|
||||
|
||||
### Known Bugs/problems/warnings/portability issues
|
||||
|
||||
Some CPPs issue a warning about empty macro parameters.
|
||||
Some `CPP`s issue a warning about empty macro parameters.
|
||||
|
||||
-pedantic informs me that 'ISO C' does not allow extra ; outside of a
|
||||
function, and I to this I say ISO what ???
|
||||
`-pedantic` informs me that 'ISO C' does not allow extra ; outside of a
|
||||
function, and to this I say to ISO what ???
|
||||
|
||||
-Wall of course will suggest adding a lot of parenthesis, function prototypes,
|
||||
`-Wall` of course will suggest adding a lot of parenthesis, function prototypes,
|
||||
and remove some unnecessary expressions, and to this I say: if I listen to you
|
||||
where is my freedom to obfuscate in style?
|
||||
|
||||
@@ -157,26 +179,26 @@ As mentioned earlier if you try to run the original program without its source
|
||||
nearby it will dump core.
|
||||
|
||||
The program relies heavily on the ASCII coding system (have I seen this
|
||||
comment before ?). It also implicitly assumes that sizeof(int) = sizeof(FILE
|
||||
*). On systems when that is not the case expect a core dump...
|
||||
comment before ?). It also implicitly assumes that `sizeof(int) = sizeof(FILE
|
||||
*)`. On systems when that is not the case expect a core dump...
|
||||
|
||||
### Challenges
|
||||
|
||||
What use are the ;; for ?
|
||||
What use are the `;;` for ?
|
||||
|
||||
Why do I use 126& in the program? (except for the rather obvious fact that it
|
||||
Why do I use `126&` in the program? (except for the rather obvious fact that it
|
||||
serves as comment obfuscater).
|
||||
|
||||
Why not write s^= instead of s=s^ In the expression I'm most proud of ?
|
||||
Why not write `s^=` instead of `s=s^` In the expression I'm most proud of ?
|
||||
|
||||
What is 40-(h&62) doing ?
|
||||
What is `40-(h&62)` doing ?
|
||||
|
||||
Use the program to solve for a different starting position. It is not that
|
||||
difficult. Notice however that if there are more than two empty spaces the
|
||||
outputs would not compile as the layout would not be sufficient to contain the
|
||||
program.
|
||||
|
||||
Use the program to solve for board size different than 4*5. Thats a bit more
|
||||
Use the program to solve for board size different than `4*5`. That's a bit more
|
||||
tricky.
|
||||
|
||||
### Hint for the challenges
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
#define/**/F/***/for/*A*/
|
||||
#define/***/H()f=*E<<4|*\
|
||||
E,f=~(f|f<<1|E[3]|E[1]|E\
|
||||
[1]<<4|E[2]|E[(2)]<<(1));
|
||||
#define/***/I(x,d)F(;s;C\
|
||||
()){s=s^(b=s&s-1^s);F(N[\
|
||||
4]=q=0;q<4;q++)N[q]=E[q]\
|
||||
;N[5]=E-B;N[d]^=+b^(b)x;}
|
||||
#define/**/o(p,t,i,m,a,l\
|
||||
\
|
||||
)u=(f&p)i(m) ;s=u&E[3];I(t(m),3)s=(u)a &E[l];I(t(m\
|
||||
),l)u=u>>5-m &u;s=u&E[3-l];I(t(m),3-l) s=(u)a&*E;I\
|
||||
(t(m),(0));; /*echo/Line/%d;sed/-n/-e/ %d,%dp/%s>*/
|
||||
/*c.c;cc/c.c /-c*/;;char*A=0,*_,*R,*Q, D[9999],*r,l
|
||||
[9999],T=42, M,V=32;long*E,k[9999],B[1 <<+21],*N=B+
|
||||
1234567,q=0, h=3,j=2,O,b,f,u,s,c,a,t,e ,d;C(){F(h=N
|
||||
[3];(B[h]&&+ memcmp(N,B+B[h],16));h=B[ h]+4);B[h]||
|
||||
(B[h]=N-B,N= N+6);}main(char*U,int*w[] ){;;F(_=A=D+
|
||||
6666,A[fread (A,1,3333,fopen(__FILE__, "r"))]=0;*++
|
||||
_;h||(*_=V))
|
||||
*_-59|_[1]-* _||(h&&(*_=+ 35),h---2||(_[9]=V));;F(_
|
||||
=A;*_;_++)10 -*_&&*_-V&&( *_-92)&&(k[q]=isalnum(l[q
|
||||
]=*_),q++);M =47;*(E=N-6) =64;E[1]=289;E[2]=270336;
|
||||
F(E[3]=32782 ;E<N;E=E+6){ H()o(1048560,<<,>>,4,>>4,
|
||||
1)o(+489335, >>,<<,1,,2)o (978670,<<,>>,1,>>1,2)o(+
|
||||
65535,>>,<<, 4,,1)if(8192 &*E){F(N=B;E>B;E=B+E[5])*
|
||||
N++=E-B;F(;N >B;){h=*(E=B +*--N);H()s=~(E[1]|h|h<<1
|
||||
);u=~(E[2]|h |h<<4);r=l;_ =D;d=1;a=2;O=8;F(q=74;q;q
|
||||
--){F(b=0;b< 72;b++){h=+1 <<(q-1)/14*4+(b-1)/18;j=b
|
||||
?(!(b%18)&&u &h)|h&f|(!(q%14)&&s&h)?1:
|
||||
0:2;if(O<3)O ?j?j-1&&(O-2 &&d--,*R=34,O=2):(*_++=O-
|
||||
2?l[d]?l[d++ ]:(d=t,O=e=3 ,34):(O=1,34)):j||(*_++=d
|
||||
<t?l[d++]:(O =1,d=0,34)); else{if(O<6)if(j){j-2|e||
|
||||
(_=R,O-4?d-- :M-_[-1]||(_ [-1]=l[d++],O=3));c=0;if(
|
||||
k[d]&k[d-1]) F(;k[d-1];++ c)d--;!d||((h=l[d])^l[d-1
|
||||
])+k[d]||!(+ 40-(h&62)&&h -125)||(c=1,d--);c-1||(c=
|
||||
2,d--);c&&(_ [-c]=M,_[1-c ]=T,O=4);j-2|e||(*_++=+92
|
||||
);}else{h=*_ ++=O-4?O-5?l [d++]:(O=3,M):(O=5,T),(_[
|
||||
-1]&&(35-h|| !(a=+1)))||( O=7,*(R=Q=_-(1))=M);}else
|
||||
{j?O-7||(O=6
|
||||
,_[-1]=59):( *_++=a-2?O-6 ?O-7?126&*++ r:(O=8,T):(O
|
||||
=7,M):(a=0,l [d]-100?(e=1 ,O=0):(e=0,O =3,35)));if(
|
||||
e==1){F(r=A= l+d;35-*A;++ A)*A-M&&*A-T ||U-1&&(*A=V
|
||||
);d=d+A-r;if (U-1){*A=0;F (j=2;13499>j &&(sprintf(l
|
||||
,r+1,j,j,O=j +75,w[1]),j= O,!system(l) ););exit(j<+
|
||||
13499);}t=d+ 9;_[-1]=l[++ d];}a-1|+j-2 ||(R-Q<3?(*(
|
||||
Q<R?R-1:R)=* Q=*R=59):(*R =M,R[-1]=T), a=2);}}j?(*_
|
||||
++=j-2?V:10, R):(R=_-1);} }R[-1]=T;*R= M;*_++=10;F(
|
||||
R=D;putchar( *R)&&_>++R;) ;}}};O-b-f-u -s-c-a-t-e;}
|
||||
@@ -12,12 +12,12 @@
|
||||
),l)u=u>>5-m &u;s=u&E[3-l];I(t(m),3-l) s=(u)a&*E;I\
|
||||
(t(m),(0));; /*echo/Line/%d;sed/-n/-e/ %d,%dp/%s>*/
|
||||
/*c.c;cc/c.c /-c*/;;char*A=0,*_,*R,*Q, D[9999],*r,l
|
||||
[9999],T=42, M,V=32;long*E,k[9999],B[1 <<+21],*N=B+
|
||||
[9999],T=42, M,V=32;int*E,k[9999],B[1 <<+21],*N=B+
|
||||
1234567,q=0, h=3,j=2,O,b,f,u,s,c,a,t,e ,d;C(){F(h=N
|
||||
[3];(B[h]&&+ memcmp(N,B+B[h],16));h=B[ h]+4);B[h]||
|
||||
(B[h]=N-B,N= N+6);}int main(int Ua,char**wa){char*U
|
||||
=Ua;int**w= wa;;F(_=A=D+6666,A[fread(A,1,3333,fopen
|
||||
(__FILE__, "r"))]=0;*++ _;h||(*_=V))
|
||||
(__FILE__, "r"))]=0;*++ _;h||(*_=V))
|
||||
*_-59|_[1]-* _||(h&&(*_=+ 35),h---2||(_[9]=V));;F(_
|
||||
=A;*_;_++)10 -*_&&*_-V&&( *_-92)&&(k[q]=isalnum(l[q
|
||||
]=*_),q++);M =47;*(E=N-6) =64;E[1]=289;E[2]=270336;
|
||||
|
||||
@@ -196,11 +196,14 @@ Please help us by writing alternative code!
|
||||
## STATUS: main() function args not allowed - please help us fix
|
||||
|
||||
Entries with this status have a problem in that the args to main() are not of a
|
||||
specific type due this being allowed in earlier C. This shows itself in some
|
||||
compilers like clang. [Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson)
|
||||
looked at the source code of clang and reported that there is no way to override
|
||||
this requirement so these entries will fail to compile with clang. That's why he
|
||||
in some entries he fixed he did it by adding a function called `pain()`. :-)
|
||||
specific type due to this being allowed in earlier C. Some compilers like clang
|
||||
have a deficiency where they do not allow this so these entries do not work with
|
||||
clang.
|
||||
|
||||
[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) looked at the source
|
||||
code of clang and reported that there is no way to override this requirement so
|
||||
these entries will fail to compile with clang. That's why in some entries he
|
||||
fixed he did it by adding a function called `pain()`. :-)
|
||||
|
||||
**NOTE for macOS users**: please be aware that _gcc_ under macOS **is actually
|
||||
clang** despite the fact it might appear to be gcc: no symlink and both gcc and
|
||||
@@ -1692,20 +1695,49 @@ strange. This might also happen if you specify excessively large board
|
||||
dimensions. Try `100 100 100` for instance and see what happens!
|
||||
|
||||
## [2005/giljade](2005/giljade/giljade.c) ([README.md](2005/giljade/README.md))
|
||||
## STATUS: doesn't work with some platforms - please help us fix
|
||||
## STATUS: known bug - please help us fix
|
||||
|
||||
[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) noted that this
|
||||
requires both 32-bit CPUs (data size?) and also cannot have the optimiser
|
||||
enabled. It might be that it can be fixed, perhaps by changing the int sizes
|
||||
and bitwise operations, but if not this will not work with some systems like
|
||||
modern Macs as Apple has made it quite difficult to compile 32-bit applications
|
||||
(thanks a lot Apple for ruining some IOCCC entries! :-) ).
|
||||
Landon Curt Noll fixed this entry to work with clang by changing the first arg
|
||||
to be an `int` and the second arg to be a `char **`. This is important because
|
||||
of clang's deficiency requiring args to be one type only.
|
||||
|
||||
It's quite probable that non x86 related CPUs will also not work: it's hard to
|
||||
know because Cody's only non-x86 (`x86_64` in particular) system is the MacBook
|
||||
Pro Max with the M1 chip which is arm64 and unfortunately specifying `-m32` is
|
||||
invalid on that system (might be on Intel 64-bit Macs as well but he hasn't had
|
||||
one since November 2022).
|
||||
This did not completely fix the problem for the program however.
|
||||
[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) observed that it has to
|
||||
be compiled with `-m32` which is not possible in modern macOS. It also cannot
|
||||
have the compiler optimiser enabled. Cody fixed it so that it works in 64-bit
|
||||
but the clang fix does break something in the entry, specifically that the
|
||||
self-test feature of the program no longer works.
|
||||
|
||||
One is supposed to be able to do:
|
||||
|
||||
```sh
|
||||
./giljade > out
|
||||
./giljade out
|
||||
```
|
||||
|
||||
and see all layouts compile without error. If you wish to see this in action and
|
||||
you have a compiler without the deficiency of clang you can do:
|
||||
|
||||
```sh
|
||||
make alt
|
||||
./giljade.alt > out
|
||||
./giljade out
|
||||
|
||||
```
|
||||
|
||||
(You don't need to use `giljade.alt` to test compile - it's the output of the
|
||||
program that's the actual problem.)
|
||||
|
||||
But the issue is can it be fixed for clang. If you have a fix we welcome your
|
||||
help! Believe it or not this appears in part to be due to more than two spaces in
|
||||
the program except in the places where the original code has them. This however
|
||||
does not seem to be the full story. Cody probably will look at this again but
|
||||
for now we note this problem here.
|
||||
|
||||
## STATUS: INABIAF - please **DO NOT** fix
|
||||
|
||||
It also will very likely segfault or do something strange if the source code
|
||||
does not exist.
|
||||
|
||||
|
||||
## [2005/mynx](2005/mynx/mynx.c) ([README.md](2005/mynx/README.md))
|
||||
|
||||
Reference in new issue
Block a user