File "changes"~~~~~~~~~~~~~~LOG of the changes introduced by Simao and summary of results.1. first of all, file names had to fit in DOS limitations. Some names had   to be truncated, and the mapping is as follows:	gsm_create.c    -> gsm_crea.c	gsm_decode.c    -> gsm_deco.c	gsm_destroy.c   -> gsm_dest.c	gsm_encode.c    -> gsm_enco.c	gsm_explode.c   -> gsm_expl.c	gsm_implode.c   -> gsm_impl.c	gsm_option.c    -> gsm_opti.c	gsm_print.c     -> gsm_prin.c	long_term.c     -> long_ter.c	preprocess.c    -> preproce.c	short_term.c    -> short_te.c2. gsm.h had added prototypes for all the existing functions3. add.c had to be changed to make add_test.c work4. private.h had to be changed to use either true-function or the safe   pseudo-functions for the GSM_... macros. This was the main reason for   the errors that were happening.   5. undefs were preceeded by a check of their definition to avoid some   complaints from VAX-C   6. rpe.c had to be changed in a strange hacked "switch" by its "normal"   implementation for VMS (compilation error!) -  the code is as it was   in comments.    7. To keep compatibility, the change in patch 3 to rpe.c    shall not be    #define STEP( i, H )    (e[ k + i ] * (long)H)   but   #define STEP( i, H )    (e[ k + i ] * (longword)H)8. long_term.c (now long_ter.c) had to have added some castings, such    as:      temp = gsm_norm( (longword)dmax << 16 );                       ^^^^^^^^^^   because gsm_norm uses longs and dmax is short: (short)<<16 = 0 always!   Also, if MSDOS/__MSDOS__ is defined, then USE_TABLE_MUL is    #undef'd (see tests below).9. other small changes that I don't recall from my notes. These may include   type castings, and other changes done in the desperate search for the bugs.   Simplifications:~~~~~~~~~~~~~~~~Since I don't want a compress-like utility, I haven't put my hands in toast.To ease my work, I've put all src, inc and add-test in one single directoryand simplified the makefile. I also added labels "all", "rpedemo" and "clean","anyway".Extensions:~~~~~~~~~~~I added a DCL for compiling on VMS using either gcc or vax-c, depending onthe comments. I have also added a borland bcc make file for the pc, as well as a gcc makefile for the pc.Added a demo program and 2 driving routines (currently embedded in the demo program). With them, interfacing with the test sequence file is straight-forward.Test results:~~~~~~~~~~~~~the bcc-compiled version processed correctly all the 5 test vectors forthe following conditions:(SASR always defined)USE_FLOAT_MUL undefinedUSE_FLOAT_MUL defined and FAST undefinedUSE_FLOAT_MUL and FAST definedbcc failed compilation when USE_FLOAT_MUL undefined and USE_TABLE_MUL defined because the table matrix is greater than 64kbytes! (No way out!)When compiled by bcc with both USE_FLOAT_MUL and FAST undefined, bccfailed passing the test sequences. Besides compilation worked for USE_FLOAT_MUL and FAST defined, in fact, allthe runs with the test sequences were made in the "compatible mode", i.e.,with the state variable structure fuield "fast" always set as 0. Therefore,it was not tested. Although, it is known from the original authors thatthe fast mode does not work in Unix (32bit), hence it is very likely notto work with DOS either!NeedFunctionPrototypes was always defined for bcc, gcc, acc, and vax-c, and undefined for unix cc.Since gcc is the same implementation ported across platforms, it should work as for SunOS, but it was not tested.The program worked properly for the following environments (see summary below):SunOS 4.3:	cc, acc, gcc	MS/DOS: 	bcc, gcc (djcpp)VAX/VMS: 	cc (Vax-c), gccSummary of the tests:-------------------------------------------------------------------------Environment	Compiler    Symbols defined (Note: SASR always def'd)			USE_FLOAT_MUL	FAST	USE_TABLE_MUL  Worked?-------------------------------------------------------------------------SunOS 4.3:	cc	yes		no	-		yes			yes		yes	-		yes*			no		-	no		yes			no		-	yes		yes		acc	same as for cc in SunOS 4.3		yes		gcc	same as for cc in SunOS 4.3		yesMS/DOS: 	bcc	yes		no	-		yes			yes		yes	-		yes			no		-	no		no			no		-	yes		no		gcc	Not tested other than yes/no/-		yesVAX/VMS: 	Vax-c	same as for cc in SunOS 4.3		yes		gcc	Not tested other than yes/no/-		yes-------------------------------------------------------------------------* Note: all the runs were made in the compatible mode, therefore the        fast computation of the data was not performed!-------------------------------------------------------------------------Therefore, the safest approach is to compile always with USE_FLOAT_MULdefined and with and FAST defined if appropriate for speed! In Vax-C there were warnings relating to function names longer than 31 characters. No way to circumvent this, but it is not a problem because the31 first letters generate unique names anyway. Because of this, link will also complain!The test sequence files had the byte order swaped in the Sun workstationbecause of the Big Endian data orientation.-- <simao@cpqd.ansp.br> -- 8/Apr/94