Fix EOF == -1 assumption in 1994/shapiro
The problem is that the getc() functions return EOF on error/EOF but it assumed that it returns -1. EOF is not required to be -1 but merely an int < 0 so on systems where it was not -1 it could be a problem. But changing the != -1 check to be != EOF caused a new compiler warning and errors. However since EOF < 0 and since the code functions fine with the check being >= 0 the code now checks that the return value of getc() >= 0 as the condition of the for loop. This takes care of any problem where EOF != -1. Fixed accidental change in shapiro.md code excerpt. Note that that one (the first one) does not actually work but it never did (or if it did it doesn't in modern systems). I'm not sure this is a problem though as the author stated that without the comments the program will not do anything right. I believe the author was showing the algorithm without comments.
This commit is contained in:
Cody Boone Ferguson committed
1 parent
e09f677b37
commit
0c543beb0f
4 files changed
+17
-89
No files matched your search
+15
-11
@@ -10,17 +10,21 @@ USA
|
||||
|
||||
make all
|
||||
|
||||
[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) pointed out a potential
|
||||
bug on systems where `EOF != -1`. The problem is that `getc()` and the related
|
||||
functions do not return `-1` on EOF or error but rather `EOF` but the program
|
||||
assumes `-1` (conversely when using the `getopt()` functions one should not
|
||||
check for EOF but -1 as the functions return -1 not EOF but the standard does
|
||||
not require `EOF` to be -1, just a negative number. However changing it to check
|
||||
for `!=EOF` caused a problem due to the clever encoding of the code. See
|
||||
[bugs.md](/bugs.md) for more details if you wish to try and fix this (Cody is
|
||||
here and there working on it along with other things and will change this
|
||||
message when it's fixed assuming it's feasible).
|
||||
|
||||
[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) fixed a bug on systems
|
||||
where `EOF != -1`. The problem is that `getc()` and the related functions do not
|
||||
return `-1` on EOF or error but rather `EOF`. However `EOF` is not required to be
|
||||
`-1` but merely an int < 0 and this program assumed that `getc()` will return
|
||||
`-1` on EOF or error, not `EOF`. On systems where `EOF != -1` it could be a
|
||||
problem. For the same reason one should not use `EOF` for the `getopt()`
|
||||
functions as they return `-1` when all options are parsed (for details on the
|
||||
definition of `EOF` see `7.21 Input/output<stdio.h>` subsection 1 of the
|
||||
standard). An interesting problem occurred where changing the `-1` to `EOF`
|
||||
caused both `warning: illegal character encoding in string literal` and `error:
|
||||
source file is not valid UTF-8`. But since `EOF` is simply an int < 0 and making
|
||||
the loop condition check that the return value is >= 0 does not cause a
|
||||
compilation error and it functions correctly it will address the systems where
|
||||
`EOF != -1` just as if it checked for `!= EOF`. Thank you Cody for your
|
||||
assistance!
|
||||
|
||||
## To run:
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
/*T*/,"r");for (;( L/*KPUOWOWMUQ
|
||||
LLOLMPULWLWL WLW LWLWLWLWLWLW
|
||||
LWLWLULVOXP LLV LLLOLMPULOL
|
||||
MMNP*/=getc (J) )!= -1;L/*
|
||||
MMNP*/=getc (J) )>= 0;L/*
|
||||
OLWLRMMQUL VOX PLLVLLLMQO
|
||||
PMPYPXPNP MQL LVLLLWPSP
|
||||
XPOQNQOPMQ LLV LTj*/>='J'
|
||||
|
||||
@@ -13,7 +13,7 @@ This is a very simple program:
|
||||
5. FILE *J;
|
||||
6. J=fopen(__FILE__,"r");
|
||||
7. for(;
|
||||
8. (L=getc(J))!=EOF;
|
||||
8. (L=getc(J))>=0;
|
||||
9. L>='J'&&L<='J'+15 &&
|
||||
10. ((M=!M)?K=L:putchar(K-'J'|(L-'J'<<4)))
|
||||
11. );
|
||||
|
||||
@@ -572,82 +572,6 @@ or was killed. See the README.md for more details. If you don't feel comfortable
|
||||
changing it to `EOF` Cody will happily do it for you but otherwise go right
|
||||
ahead. We'll credit you in the README.md file regardless.
|
||||
|
||||
|
||||
## STATUS: doesn't work with some platforms - please help us fix
|
||||
|
||||
[Cody Boone Ferguson](/winners.html#Cody_Boone_Ferguson) pointed out a potential
|
||||
bug in [1994/shapiro](1994/shapiro/shapiro.c) on systems where `EOF != -1` as
|
||||
the code assumes that `EOF` will always be `-1`. As the standard says (see `7.21
|
||||
Input/output<stdio.h>` subsection 1) it only has to be a negative int, not
|
||||
necessarily `-1`. The problem is that the source file's last character is a
|
||||
newline (10 in decimal) and so on systems where `EOF != -1` the `getc()`
|
||||
functions would not terminate the loop (but see below). This would cause a
|
||||
breakage in the entry.
|
||||
|
||||
However due to clever encoding of the code it is not a simple matter of applying
|
||||
the following patch:
|
||||
|
||||
```diff
|
||||
diff --git i/1994/shapiro/shapiro.c w/1994/shapiro/shapiro.c
|
||||
index d2da120c7bc4e251b7624859e48f47f188d398e9..e054a1ceb067b82bf37c07e5ce75e82be7a03b85 100644
|
||||
--- i/1994/shapiro/shapiro.c
|
||||
+++ w/1994/shapiro/shapiro.c
|
||||
@@ -9,11 +9,11 @@
|
||||
/*PPPPVPOQMQRPR*/=0;FILE/*TPSLUMWQT*/ *
|
||||
J/*MPRPKPLQ*/; J= fopen(__FILE__
|
||||
/*T*/,"r");for (;( L/*KPUOWOWMUQ
|
||||
LLOLMPULWLWL WLW LWLWLWLWLWLW
|
||||
LWLWLULVOXP LLV LLLOLMPULOL
|
||||
- MMNP*/=getc (J) )!= -1;L/*
|
||||
+ MMNP*/=getc (J) )!=EOF;L/*
|
||||
OLWLRMMQUL VOX PLLVLLLMQO
|
||||
PMPYPXPNP MQL LVLLLWPSP
|
||||
XPOQNQOPMQ LLV LTj*/>='J'
|
||||
&&L/*LRPYP OQL QMQLLVLLL
|
||||
OLMQVOXPL LVL LLVOe*/<=
|
||||
|
||||
```
|
||||
|
||||
as doing so will cause `warning: illegal character encoding in string
|
||||
literal` and the error `error: source file is not valid UTF-8`. Looking at the
|
||||
file you'll see on line 4 of `shapiro_t2.c`:
|
||||
|
||||
|
||||
```
|
||||
char *a[]={"%c+------------+\n","%c+%3dPRÒ<82>3·Âå&Â"2W6öæF6'Â"Ò<96>æVGW6'¢ <82>öV'7'Â"R2Çå&Â"Â^E33sÃ^E33³UB¶cS³<83>T2Ç^E33<83>#Ò·£<90>æF^G"¶ÕÕ³^GÃ^BÃ^RsÃ^RCÃ^R^SÃ^BÓ·£Ð^V<96>æ<86>bÇ2<96><92>æF^Gb·3<86>^V&^G¢¢^B2¶£°7<86>^V&^GB¶E^CÓÅ¢RÆbÖc³£@<97>ÖVöE^Gr¶£`<94>ÄT^D¢<82>Æ¢<92>¶£p<87><96>ÆV^F<82>ÒÒb^Fbb^B^R^B<97>^FW<86>B<96>^Bbb^B^Rbö&·<86><92><92>²£<80>ÖcFö^FWæ<86>bÓbÆÃ^SÃ"^R&<92>²<93>ÖcFö^FWæ<86><82>bÓbÆÃ^S<93>²^RÃ""'<92>²£`ö&<87>²³<93>²<97>f<86>b<96>²gvVF7<87>BÆB^CÃ<92><96>²C¶5G'ÇVæ<86>B<96>Ò^RÓÕsÂ^Es²£<90>f<86>¢BÖÓs^Bs²b<96>²7^G'<97>æFg<86>¢2Æ"R2Çå&ÂB¶^R<93>²ó<86>2GGöVGÇbÃbÓbÆB¶^RÃ^B<93>Ò§<90>f<86>¢Bæs^Bs²b<96>ò<86><82>ÆRÃBÆ^BÃ^B<93>ÒWÆ6W¶G<97>ÖV<86>br<96>²SÖ^S67F<97>ÖV<86>Âö6^VÆF<97>ÖV<86>br<96><92>²£`ö&<87>b×^S³cÇc³c·²<92>ò<86><82>Æb^WÒ^Scbb^WÒcÓ^RÃb·r^BsÂ^RF÷<96><86>R¶"¶e×<95>Âb<97>2ÇVV^F<87>^R<93>²Ó×ק
|
||||
```
|
||||
|
||||
when it should be something entirely different. For what it should be try
|
||||
running `make clobber all ; cat shapiro_t2.c` or else look at the second program
|
||||
in the spoilers file [shapiro.md](1994/shapiro/shapiro.md]).
|
||||
|
||||
Cody is working will be working on this here and there but if you have a fix or
|
||||
any suggestions you're welcome to provide it or them.
|
||||
|
||||
Cody points you to the README.md file for what should happen when the entry is
|
||||
successfully compiled (including no compilation errors when running `make
|
||||
clobber all`).
|
||||
|
||||
Another problem is that in the [shapiro.md](shapiro.md) file the first program
|
||||
does not work.
|
||||
|
||||
### Tips on this entry:
|
||||
|
||||
Cody provides some tips on this entry:
|
||||
|
||||
First: the comments are the important part of this entry. Remove them and the
|
||||
program breaks.
|
||||
|
||||
Second and perhaps part of the problem with changing the code to `EOF` instead
|
||||
of `-1` is the `for` loop particularly to do with the bitwise operations,
|
||||
perhaps also made worse by the seemingly gibberish comments.
|
||||
|
||||
Another important point is that the Makefile compiles the program as
|
||||
`shapiro_t1` so that the source code that corresponds with it is actually
|
||||
[shapiro.c](1994/shapiro/shapiro.c). But notice how running `shapiro_t1` results
|
||||
in different functionality than `shapiro` itself? The source code that
|
||||
`shapiro_t1` generates, `shapiro_t2.c`, is what is compiled into `shapiro`.
|
||||
|
||||
# 1995
|
||||
|
||||
|
||||
|
||||
Reference in new issue
Block a user