I have now found and eliminated the bug I told you of in my last mail.
It was, as suspected in the 'my_receive' routine.  There you had a small
'if' clause that incremented 'walk' to ignore an initial END marker.

What you had forgotten was that though this marker might be initial to
the new block of data read, it could still be a correct terminator for
older data, residing at addresses below those now to be scanned...

The problem was first fixed by simply erasing that 'if' clause, but as
I was digging into this code anyway I took the opportunity to clean up
the structure a bit, by eliminating a redundant nestled loop.

I then added some error handling for illegally short blocks, which you
had missed earlier, and corrected the legality limit to three bytes, as
that is apparently the minimum header size for VJHC-compressed packets.
Illegal headers will still be detected by 'process_datagram' of course.

As suggested in earlier mail I have now altered the author string in the
driver struct to include a 'team name'.  Unfortunately I had missed two
spaces in the alerts of STING.CPX, so I suddenly discovered that the name
I suggested earlier is too long.  I settled for "STinG Evolution Team"
instead, which in some ways is even nicer.  :-)

A less pleasant consequence of the 'discovery' of those two spaces is that
the author strings I have used in several publicly released modules are two
characters too long.  They will result in alert strings of 31 characters,
and that can cause singleTOS to bomb unless AES enhancements are active that
prevent this.  On my systems they normally are, so I have missed this.  :-(

The attached archive includes all sources used to compile version 1.17, and
as soon as you verify the changes I made as correct, I will release the STX
to the beta crew for more extended testing.


PS: I almost forgot, but one additional change I made was to edit some of
    the declarations of 'co_stat', 'con_stat', etc, and the functions that
    need them as arguments.  The reason for this change is that there are
    some old bugs in the prototypes declared in the standard TOS.H, which
    claims that none of the MAPTAB functions have any arguments, and that
    they are not of CDECL type (as would be irrelevant without args). The
    error is clearly in that declaration of MAPTAB, but as this is now a
    standard type we have to adapt to it, so I changed some declarations
    to allow compilation without warnings about 'suspicious pointers'.
DS.

-- 
-------------------------------------------------------------------------
Regards:  Ronald Andersson                  mailto:dlanor@ettnet.se
http://dlanor.atari.org/    ICQ:38857203    http://www.ettnet.se/~dlanor/
-------------------------------------------------------------------------
