home *** CD-ROM | disk | FTP | other *** search
/ Fish 'n' More 2 / fishmore-publicdomainlibraryvol.ii1991xetec.iso / dirs / northc_384.lzh / NorthC / NorthC2.LZH / bin / Bugs.doc < prev    next >
Text File  |  1990-09-07  |  9KB  |  291 lines
  1.  
  2.   (c) 1990 S.Hawtin.
  3.   Permission is granted to copy this file and NorthC provided that:
  4.    1) Neither are used for commercial gain
  5.    2) This notice is included in all copies
  6.    3) Altered copies are marked as such
  7.    4) Each copy of NorthC is accompanied by a copy of this file.
  8.  
  9.   No liability is accepted for the contents of the file or the NorthC program.
  10.  
  11.   Bugs.doc      within        NorthC
  12.  
  13.   This file gives some hints about problems with "NorthC" programs, if you 
  14. find that a program you have compiled is behaving in a way you really 
  15. cannot explain and "libc.doc" is no help, you should read this file.
  16.  
  17.   This file is split into three sections, first the list of known bugs in 
  18. the current release, next a list of bugs fixed by this and previous 
  19. releases and finally a list of "hints".
  20.  
  21.   The known bugs are listed under the release that they were first noticed 
  22. in, the fixes are listed under the release that they were implemented in.
  23.  
  24.   The "hints" cover everything from bugs I have no immediate intention of 
  25. fixing to problems with the 'C' language that have caught me out in the past.
  26.  
  27.  Bugs
  28.  ****
  29.  
  30.  Version 1.2
  31.  ***********
  32.  
  33. 1.2.6  unsigned short Function Arguments
  34.  
  35.   Because all integers are now four bytes there seems to be a problem with 
  36. functions that have unsigned short arguments.  The calling function expands 
  37. these two byte values into four bytes but the called function assumes they 
  38. are two bytes long, and wowee we have messed the stack up.
  39.  
  40. 1.2.7  "%hd" qualifier in printf
  41.  
  42.   The short qualifier "h" does not work in printf.
  43.  
  44.  Version 1.1
  45.  ***********
  46.  
  47. 1.1.1  Standard C
  48.  
  49.   There are a number of features of ANSI 'C' that are not implemented in 
  50. NorthC.  NorthC is a fairly standard Kernigan & Ritchie first edition 'C' 
  51. that has been extended to move towards ANSI.
  52.  
  53.   The features that I know are missing are
  54.  
  55.     a)  locales
  56.     b)  structure returns
  57.     c)  function prototypes
  58.     d)  #pragma #val #error
  59.     e)  The '#' and '##' operators
  60.     f)  concatenating adjacent strings
  61.     g)  multibyte characters
  62.     h)  floats & doubles are too small
  63.     i)  volatile and const storage classes
  64.  
  65. 1.1.2  Assignments in if statements
  66.  
  67.   The assignment operator can be incorrectly optimised away in some 
  68. situations, for example the code
  69.  
  70.     if(x=7)
  71.        {printf("foo");
  72.         }
  73.  
  74. will notice that the assignment always returns a true value and so will 
  75. just call printf() without bothering to perform the assignment.  The 
  76. obvious fix is to convert the code to
  77.  
  78.     x=7;
  79.     printf("foo");
  80.  
  81. to force the assignment.  If you typed the first code fragment I would 
  82. imagine that you meant
  83.  
  84.     if(x==7)
  85.        {printf("foo");
  86.         }
  87.  
  88. which is entirely different and of course works.
  89.  
  90. 1.1.3  Library functions
  91.  
  92.   The library functions do not always act as expected, see "libc.doc" for 
  93. a complete description of the bugs and omissions.
  94.  
  95.   The system() function always returns -1 regardless of the value returned 
  96. by the called program.
  97.  
  98.   scanf() does not fully support floating point numbers, see the note in 
  99. the Hints section.1.1.5  Program name
  100.  
  101.   When a program is started up it should have its name in argv[0], however 
  102. NorthC always sets this string to "".  This will confuse some programs, 
  103. for example the UNIX "uncompress" and "compress" programs rely on knowing 
  104. the name they were called with.
  105.  
  106. 1.1.6  fseek()
  107.  
  108.   There are some occasions when fseek() functions incorrectly, as yet I 
  109. have no consistent example of this bug.
  110.  
  111.  Release 1.0
  112.  ***********
  113.  
  114.   All the bugs reported in release 1.0 have been fixed.
  115.  
  116.  Fixes
  117.  *****
  118.  
  119.   Here is a list of previously noted bugs that are now fixed.
  120.  
  121.  Release 1.2
  122.  ***********
  123.  
  124. 1.2.1  strtol()
  125.  
  126. 1.1.4  Clearing address registers
  127.  
  128. 1.0.1a  Declarations inside functions
  129.  
  130. 1.2.2  #undef (from M.Combs)
  131.  
  132. 1.2.4  Initialised static arrays in functions
  133.  
  134. 1.2.5  fgetc() return value.
  135.  
  136. 1.2.3  open() in the UNIX library
  137.  
  138. 1.2.8  Initialising unsigned char arrays (from M.Combs)
  139.  
  140. 1.2.9  ctime() and asctime() (from M.Combs)
  141.  
  142.  Release 1.1
  143.  ***********
  144.  
  145. 1.0.1b  Declarations inside functions
  146.  
  147.  Hints
  148.  *****
  149.  
  150.   Large numbers of functions have not yet been implemented, or behave 
  151. differently from ANSI, see the "libc.doc" file for details.  If you find 
  152. any functions that you really need are not yet done you will have to write 
  153. them yourself.
  154.  
  155.   scanf() and all its relatives, behave in counter intuitive ways.  If you 
  156. use these functions you might have problems getting programs to work, and 
  157. you will certainly have problems porting your programs between machines, I 
  158. know for sure that there is a difference between NorthC scanf() and the 
  159. one in UNIX V.  However the version of scanf() under UNIX doesn't work 
  160. either.  I might not fix this problem, I have yet to find two versions of 
  161. 'C' that do the same thing with scanf(), I would recommend you just don't 
  162. use it.
  163.  
  164.   If the compiler suddenly starts crashing the machine whenever it is run 
  165. check how full the disk is.  If the OS returns a "disk full" error the 
  166. compiler may just carry on writing to the disk regardless.
  167.  
  168.   If your program dies with a message like "Error: 1004" this indicates a 
  169. library error, look in the ":include/errno.h" file to find out what the 
  170. library function is complaining about, or use the strerror() function.
  171.  
  172.   The compiler examines the value of the "INCLUDE" environment variable 
  173. and adds the listed directories to its include directories.  Separate 
  174. directories should have a ',' character between them.  For example to look 
  175. on the directories "df1:foo" "//jim" and "fred" issue the CLI command 
  176.  
  177.     setenv INCLUDE "df1:foo,//jim,fred"
  178.  
  179. this feature has not been fully tested yet so it may be interesting to use.
  180.  
  181.   Here is a classic mistake that all real 'C' programmers must make at 
  182. least once, beware of the difference between
  183.  
  184.     if(jim==foo())
  185.        {.
  186.         .
  187.         }
  188.  
  189. and
  190.  
  191.     if(jim=foo())
  192.        {.
  193.         .
  194.         }
  195.  
  196. one of these is an assignment the other is a test, both are valid 'C'.  
  197. Some programmers guard against this by using
  198.  
  199.     #define EQ ==
  200.     .
  201.     .
  202.     if(jim EQ foo())
  203.        {.
  204.         .
  205.         }
  206.  
  207. of course you would put the first definition in an include file, 
  208. "easyC.h"for example.
  209.  
  210.  
  211.   Large programs may cause Blink to have some problems, if you find that 
  212. some symbols refuse to link in very large programs try setting the 
  213. "SMALLCODE" flag.  If you keep finding that Blink is failing to link 
  214. symbols you know are defined try linking with the command
  215.  
  216.     cc -ooutname -bSMALLCODE foo.o bar.o baz.o
  217.  
  218. this fixes the problem for my largest program, NorthC.
  219.  
  220.   In general if the linker is causing problems it is worth setting it to 
  221. verbose, us a command such as
  222.  
  223.     cc -ooutname -bVERBOSE foo.o bar.o baz.o
  224.  
  225. this will at least give a clue as to where the linker problem was.
  226.  
  227.   There is no way at the moment to handle interrupts within NorthC, this 
  228. should be fixed when I find a book that explains what to do to handle them 
  229. in AmigaDOS.
  230.  
  231.   If you want to play with assembler then just call "NorthC" on your ".c" 
  232. file, this will produce a ".s" file that you can examine.  The "make" 
  233. program knows how to create object files from ".s" files.
  234.  
  235.   Look at "crt0.asm" to see how I have used the assembler, there may be 
  236. some good ideas to steal.
  237.  
  238.   When writing assembler be sure to restore the registers before you 
  239. return, NorthC expects you to alter the registers d0 d1 a0 and a1 but any 
  240. other registers must be restored or else very nasty things can happen.
  241.  
  242.   If you want to play with the low levels of the operating system I would 
  243. recommend that you use the debug() routine a lot.
  244.  
  245.   Here is another classic 'C' mistake,
  246.  
  247.     jim = 4;
  248.     joe = jim<<2 + 3;
  249.  
  250. this will set joe to 128, not 19 as you might expect (well I would).  When 
  251. using the shift operator always put brackets to make the nesting obvious.
  252.  
  253.   Array indices always start at 0 and go up to the number of elements 
  254. minus one.  This can have some interesting effect, for example the function
  255.  
  256.     foo()
  257.        {
  258.         int i;
  259.         int array[4];
  260.  
  261.         for(i=0;i<=4;i++)
  262.             array[i] = 0;
  263.         .
  264.         .
  265.         }
  266.  
  267. could be an infinite loop, because when the function sets array[4] to zero 
  268. it actually sets i to zero.
  269.  
  270.   Always use the system include files to define the library functions, for 
  271. example if you write some code
  272.  
  273.     foo()
  274.        {extern long atol();
  275.         .
  276.         .
  277.         jim = atol(str);
  278.         }
  279.  
  280. then NorthC will give an error message, this is because atol() is defined 
  281. as a macro in NorthC.  The correct way to access the function is
  282.  
  283.     #include <stdlib.h>
  284.  
  285.     foo()
  286.        {
  287.         jim = atol(str);
  288.         }
  289.  
  290. this will obtain the correct definition from the "stddef.h" file.
  291.