home *** CD-ROM | disk | FTP | other *** search
- How I ported 'e' version 4.8 to other environment.
- -- a brief history.
- 1) began to use 'e' in October 1985
- 2) tried to port it to 68K, but failed.
- at least 12 whole days were spent in debugging.
- the sole tool was DDT of Digital Research.
- 3) acquired 'qed' March 1986
- re-wrote my half-cooked 'e' after 'qed'
- at least 3 whole days were spent in debugging.
- 4) wrote to Mr Haefner, the author of 'qed', asking to send me
- his VAX version of 'qed'.
- 'qev' arrived.
- 5) re-wrote 'qed' without referencing my half-done 'e'
- it ran immediately.
- a few bugs were found, but a whole day was enough to
- fix them.
- all the re-writing of 'e' were erased from earth.
- that was in the first week of July 1986
- 6) re-wrote 'e' referencing my own 'qed'
- the re-writing took an hour.
- serious debugging for a few days.
- 7) ran 'lint'
- a few bugs in 'qev' were found and fixed.
- minor changes are made in order not to offend 'lint'
- too much.
- 8) submitted to CUG some time after July 1986.
- 9) present version contains a couple of fixes.
- 10 June 1987
-
- **** what things are non-portable in BDS C **
- The original 'e' was written in BDS C, which is a C language in its own
- right. However, it is different from the standard C compilers (the PCC).
- And DRI C is a descendant of the PCC. The problem is that it is precisely
- where C is most C-like that BDS C diverts from PCC. It is true that C
- is not good for programs exceeding 10000 lines,but even in the range of
- more than 2000 lines, BDS C programs are very hard to maintain because
- it lacks statics, initialisers, bit fields, typedefs, casts etc. and
- encourages the using of externals for sheer speed.
-
- The major difference between BDS C and PCC are summarized in BDS C's
- Manual Chapter Four "Notes to Appendix A of the C Book".
- A few things should be added:
- 1) identifiers must be significant in the first SEVEN letters,
- and preferrably SIX (in Honeywell). Thus, putline and
- putlineno cannot go together.
- 2) the external declaration in BDS C is almost FORTRAN. storage
- must be declared once in one file. array could be otherwise.
- 3) =op Some compilers support old fashioned operators
- though they usually print a warning. Put a space between
- them.
- #define FOO -1
- bar =FOO+1; /* bar -= 1+1; not bar =0; */
- 4) CR,LF <--> LF exchanges and EOF mark for ASCII files are handled
- implicitly in other CP/M C compilers so as to keep user
- written code close to UNIX C.
- 5) in BDS C char type is the standard type, not 'int' ( in 'for',
- 'while', 'switch' ). In BDS C, 'int' is used either as
- a pointer or as a number greater than 255.
- 6) as 'static' class is not supported in BDS C and external
- variables are faster in 8080, programs written in that
- language tend to be overloaded with externals, creating
- unreadability. Externals should be employed sparingly.
- 7) most of the functions in BDS C differ from UNIX C.
- 8) whereas UNIX C's support or understand structure assignment and
- therefore distinguishe 'foo' from '&foo' when 'foo' is a
- structure, BDS C takes 'foo' for a pointer to the structure
- 'foo'(it reminds us of the usage of array !).
- 9) that && and || have the same precedence in BDS C sometimes
- creates a crash. That is serious.
- BDS C:
- if(A && B || C)
- UNIX C:
- if(A && (B||C))