The Dink Network

Easy now. I agree that as a peasant, I am new to this forum and I do seem to question many coding techniques. Perhaps Luke is a little harsh, but only time will tell whether I am adding positive dialog or merely whining, as you suggest.

My read of the functions are
if script.d then use decompress.
if script.c then use decompress_nocomp.
the 2 are essentially the same except for this fact and the value of c(0).

if ((c = getc(in)) > 255)
fread(pair,2,c-128,in);
else

This says clearly,
if c > 255 then fread(pair,2,c-128,in)
// Parse in pairs
if c =< 255 then else
// Parse in single (ascii) characters

C is the character already read. If C >= 128, it's the number of pair definitions following in the file. ((c-128)*2 bytes in the table)
C is NOT intended to be byte-sized. C, as returned from getc()...

I believe that is what I said in answer to Drink's original question.
in "(c = getc(in)) > 255" it reads one character from a file. "c" is short. Then, c > 255 will never occur, right?

If c > 255 always returned false as you suggest, then the function would never execute the
fread(pair,2,c-128,in); and would never acknowledge the pairs table, if one existed. Everything in cbuf would be only tested for CR/LF/Whitespace or parsed as text.

If a non-ascii char was then found in cbuf, it would generate an error which has not been dealt with. However, by testing to see if a pairs table existed, then the non-ascii value would be treated as data value rather than text.

imho, Seth was not merely killing code he used the 2 functions to allow compiled.D and non-compiled.C scripts to both be usable. This should also prove out that script.D should take precedence over script.C, but this gets far away from Drink's question.

I stand that c > 255 is NOT a bug, but this is how Seth is testing for the existence of a pairs table.
mm