Another Silly programming puzzle....

[Chris Torek]

In article <1039 at cs.rit.edu> dgr0093%ritcv at cs.rit.edu (340 Ok) writes:
>I wasn't going to post this, but decoding rot13 text is much easier than that
>last program would indicate. ...

Not necessarily:

>type
>  line = string[120];
	...
>      case inp[count] of
>        'A'..'M', 'a'..'m': inp[count] := chr(ord(inp[count])+13);
>        'N'..'Z', 'n'..'z': inp[count] := chr(ord(inp[count])-13)
	...
>  if paramcount > 0 then begin
>    close (input);
>    assign (input, paramstr(1));
>    {$I-} reset (input); {$I+}
>    if ioresult <> 0 then begin
	...

`Gee, I tried this program on the IBM% and it failed.  After making
it compile by ripping out the param code, I got really weird output.
Can anyone explain this?' :-)
-----
% that means `370-derivative machine', not `IBM PC'
-----

Hint: it also fails on a Univac 1100 series machine if you run it in
Fieldata mode, rather than ASCII.

It is possible to write this program in portable C (such that it runs
on IBM 370-architecture systems, Fieldata machines, CDC's 6-bit codes,
etc., assuming you can compile under those machines in the first place)
by using the library `is*' routines.  It may be possible to write it
in portable ISO Pascal, but the above is not it.  Indeed, the above
fails miserably on input without newlines.

I guess the moral is: if you post Pascal code to comp.lang.c, look
out! :-)  (I overrode the followup-to line to get this into comp.lang.pascal
rather than comp.lang.c, and put in my own to send followups to
comp.lang.pascal.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris