home *** CD-ROM | disk | FTP | other *** search
/ ST-Computer Leser-CD 2001 January / LCD_01_2001.iso / updates / xaaes904 / docs / prtablty.txt < prev    next >
Encoding:
Text File  |  2000-09-06  |  3.9 KB  |  84 lines
  1. Portability issues
  2. ==================
  3. As released, the XaAES beta7+ source archive compiles and works under
  4. Lattice C and GCC and it would be nice if it could be kept that way.
  5. TurboC/PureC compatibility would also be nice, but I have not been able
  6. test that now (and I'm not sure it has ever really worked before).
  7.  
  8. HR: Well, Beta 8 is based on Pure C.
  9.     And because Pure C can do nothing but ANSI, there should be no problem
  10.     with other ANSI compilers.
  11.     NB: I carefully kept using short for int.
  12.     NB: v0.8 doesnt need the mintlib anymore, which greatly reduces
  13.         porting efforts.
  14.  
  15. Naturally, not all developers have access to more than one compiler, but
  16. it's not really difficult to stay out of trouble.
  17.  
  18. The most important thing to remember is that an 'int' is a 16 bit number
  19. when compiled with TurboC/PureC and GCC (as set up in the Makefile),
  20. while it's 32 bit under Lattice C (as set up in the Makefile/.PRJ).
  21. For TurboC/PureC there's no way to change this, but the other two
  22. compilers can actually handle both sizes (if you change this, there's
  23. no telling what might happen, though ;-).
  24.  
  25. To avoid problems with integers, the following rules go a long way:
  26.  
  27. - Don't use the 'int' type at all!
  28.   There are none in the XaAES source right now and there's no reason
  29.   to add any. Use 'short' and 'long' as appropriate.
  30.  
  31. - Always make sure that you avoid overflowing 16 bit 'int'!
  32.   Unless anything else is specified, C defines that arithmetic should
  33.   be done with numbers of the type 'int'. This means that with Lattice,
  34.   the following will always be fine
  35.      mem = malloc(n * s);          /* short n, s; */
  36.   since the multiplication will yield an 'int' with the correct result.
  37.   With the other two compilers, the 'int' is 16 bit and so will the
  38.   result be, which means the result of the multiplication will not be
  39.   correct if it doesn't fit in 16 bits.
  40.   The way around this is to make sure the calculation is done with
  41.   'long' numbers, since that guarantees a 'long' result:
  42.      mem = malloc((long)n * s);    /* short n, s; */
  43.   Notice that it's enough to cast one of the numbers to 'long'.
  44.   if an ordinary digit, like '2', is an 'int', while '2L' is a 'long'.
  45.   A similar thing which is easy to miss is when a shift is used:
  46.      mask = number << 16;          /* long mask;    short number; */
  47.   When 'int' is 16 bit, the result will always be 0 above.
  48.  
  49. Other potential problems can be found in areas where the ANSI standard
  50. doesn't specify something, such as whether a 'char' is signed or not:
  51.  
  52. - Be careful with 'char' variables that are used in calculations!
  53.   In some compilers 'char' is unsigned and in others it's signed.
  54.   Sometimes this can even be changed via switches/options.
  55.   This means that for example
  56.      sum += c;                     /* short sum;    char c = 0xff; */
  57.   will add 255 to 'sum' if 'char' is unsigned and subtract 1 if
  58.   'char' is signed.
  59.   If you need to do something like the above, specify signed/unsigned
  60.   explicitly.
  61.  
  62. Some compilers implement extensions to the ANSI standard, but others
  63. may not understand those:
  64.  
  65. - Multi-character constants are not part of the ANSI standard and
  66.   GCC does not support them. So, instead of using for example
  67.      if (cookie == 'MiNT')
  68.   you'll have to compare with a number. Naturally, a #define or
  69.   a comment is a good idea when you do this kind of thing.
  70.  
  71. - C++ style comments
  72.      //  This is a comment
  73.   are not part of ANSI C and may not work on all compilers.
  74.   Stay with the normal C comments.
  75.  
  76. - Nested comments are not supported by all compilers.
  77.   A better way to remove code temporarily is to use #if 0 ... #endif.
  78.  
  79. Include files are not always quite the same on all the compilers.
  80. Currently we use the MiNT libs, though, so this should not be a problem.
  81.  
  82. Using uppercase letters for include file names can cause problems for
  83. some compilers on some file systems, so avoid that.
  84.