home *** CD-ROM | disk | FTP | other *** search
/ Power-Programmierung / CD2.mdf / c / tutorial / c__tutor / tctutr_1 / tc_bug00.doc < prev   
Encoding:
Text File  |  1987-06-14  |  7.0 KB  |  230 lines
  1.  *****
  2.  
  3.    The following bugs were listed by Gene Alm on 14 June 1987.
  4.    As of this writing, they have NOT been reported to Frank
  5.    Borland by the reporter.  They will be reported within a day
  6.    or two.
  7.  
  8.    ***
  9.  
  10.       Error Class:  Error in math.h
  11.  
  12.       In the header file math.h, you will find:
  13.     
  14.         #define M_PI              3.14159265358979224
  15.   
  16.       This should read:
  17.   
  18.         #define M_PI              3.14159265358979324
  19.   
  20.       Reference:  Don Knuth, Seminumerical Algorithms
  21.   
  22.       Comments:  I have not checked any other values.  Are
  23.                  there any other dumb errors in these
  24.                  constants???
  25.  
  26.       Disposition:  Unreported
  27.   
  28.    ***
  29.  
  30.       Error Class:  Documentation error
  31.  
  32.         On page 144 of the Users Guide, there is an error in
  33.         the syntax shown for enumerated variables.  It reads:
  34.  
  35.           enum days = { Sun, Mon, Tues, Wed,
  36.                         Thurs, Fri, Sat };
  37.  
  38.         It should read:
  39.   
  40.           enum days { Sun, Mon, Tues, Wed,
  41.                         Thurs, Fri, Sat };
  42.  
  43.       Reference:  Lattice C Compiler Version 3.00 Technical
  44.                   Bulletin
  45.  
  46.       Comments:  The enum data type is quite a bit more flexible
  47.                  than implied in the illustration given.  Consult
  48.                  a good reference.
  49.  
  50.       Disposition:  Unreported
  51.  
  52.    ***
  53.  
  54.       Error Class:  Documentation error
  55.  
  56.         On page 297 of the Reference Guide, it states that the
  57.         -nxxx environment option sends the .OBJ and .ASM files
  58.         to the directory or path given in xxx.
  59.  
  60.         It ALSO sends load modules (.EXE) files to this path.
  61.  
  62.       Reference:  Try it and see!
  63.  
  64.       Comments:  I like to send temporary files (I usually
  65.                  consider .OBJ files as temporaries) to a ramdisk
  66.                  for speed but like to keep load modules on the
  67.                  current drive (hard disk).  The command line
  68.                  options by themselves don't seem to support
  69.                  sending .OBJ and .EXE files to different drives
  70.                  (paths).
  71.  
  72.       Disposition:  Unreported
  73.  
  74.    ***
  75.  
  76.       Error Class:  Documentation error
  77.  
  78.         On page 18 of the Reference Guide, the usage for _fmode
  79.         is shown as:
  80.  
  81.           extern int _fmode;
  82.  
  83.         If you look in the fcntl.h header file, you will discover
  84.         that the declaration is:
  85.  
  86.           extern unsigned _Cdecl _fmode;
  87.  
  88.         This confusion between an integer and an unsigned may
  89.         manifest itself in a warning message during compilation.  
  90.         
  91.       Reference:  See for yourself!
  92.  
  93.       Comments:  This is a common nuisance for a new product.
  94.                  The documentation doesn't agree with the facts.
  95.                  So assume the facts are correct.  Go with the
  96.                  declaration as shown in the header file since
  97.                  it is PROBABLY more current than the manual.
  98.  
  99.       Disposition:  Unreported
  100.  
  101.    ***
  102.  
  103.       Error class:  Compiler error
  104.  
  105.         If the following code is compiled, the compiler will return
  106.         a message that "code in line 9 has no effect."  Well
  107.         that is not true since if you execute the program the results
  108.         that are listed via the two printf statements are different.
  109.         The code does indeed have an effect.  Fortunately the compiler
  110.         ignores its own warning and generates the correct code for a
  111.         statement that it says is redundant.  The statement is
  112.         syntactically correct.  The leading asterisk indicates a
  113.         dereferencing that is not used and this appears to be the
  114.         problem that the compiler recoginzes.  Removing this asterisk
  115.         causes the message to disappear.  But in C, I am allowed to
  116.         do what I want to do even if it makes no sense!  The compiler
  117.         should issue a redundant operator message, not a redundant
  118.         code message!
  119.         
  120.         static int  a[] = {0, 1, 2, 3, 4};
  121.         static int  *p[] = {a, a+1, a+2, a+3, a+4};
  122.         static int  **pp;
  123.   
  124.         void main () {
  125.         
  126.           pp = p;
  127.           printf ("\n%10d%10d%10d", pp-p, *pp-a, **pp);
  128.           *++*pp;
  129.           printf ("\n%10d%10d%10d", pp-p, *pp-a, **pp);
  130.         }
  131.  
  132.         Reference:  Kernighan and Ritchie
  133.  
  134.         Comments:  When receiving a message such as "code is
  135.                    bad", just how much of it is bad?  If the compiler
  136.                    recognizes redundant operators or statements,
  137.                    it might well inform the programmer of the "find".
  138.                    Other compilers don't inform the user that a
  139.                    redundant construct has been used.  I am delighted
  140.                    that this environment tells me about it.  More
  141.                    often than not, such a message will indicate that
  142.                    there is a problem.  But don't simply say that code
  143.                    is bad.  
  144.  
  145.         Disposition:  Unreported
  146.  
  147.    ***
  148.  
  149.         Documentation error
  150.  
  151.           On page 78 of the Reference Guide, the usage for
  152.           farcoreleft is given as:
  153.   
  154.             long farcoreleft (void);
  155.  
  156.           In the alloc.h header file, the prototype is shown as:
  157.   
  158.             unsigned long _Cdecl farcoreleft(void);
  159.  
  160.         Reference:  See for yourself
  161.  
  162.         Comments:  Once again, if the documentation differs from
  163.                    the information given in a header file, assume
  164.                    that the header file contains the latest, and
  165.                    therefore the most correct information.
  166.   
  167.         Disposition:  Unreported
  168.  
  169.   ***
  170.  
  171.         Error class:  Compiler error
  172.  
  173.           When the following program is executed, you will get
  174.           two different results.  Casting values in the expression
  175.           for xr0 does not alter the situation.  
  176.  
  177.           #define   MAX_POINTS  16
  178.    
  179.           main () {
  180.    
  181.             int      points, index;
  182.             double   xr0, xr1;
  183.  
  184.             points = MAX_POINTS;
  185.             for (index = 0; index < points; index++) {
  186.               xr0 = 512.0 / MAX_POINTS * index;
  187.               xr1 = 512 / MAX_POINTS * index;
  188.               printf ("\n%20.6lf%20.6lf", xr0, xr1);
  189.             }
  190.           }
  191.  
  192.         Reference:  Kernighan and Ritchie
  193.  
  194.         Comments:  If the order of the terms in xr0 is changed
  195.                    (xr0 = 512.0 * index / MAX_POINTS), the results
  196.                    will change.  Since the order of the terms should
  197.                    make no difference, this is a serious bug.  Other
  198.                    compilers handle the above code with no problem.
  199.                    It appears as though the compiler doesn't like
  200.                    the appearance of two constants together.  If
  201.                    you suspect this problem, interchange the order
  202.                    of the terms.
  203.  
  204.         Disposition:  Unreported
  205.  
  206.    ***
  207.  
  208.  
  209.  
  210.  
  211.  
  212.        
  213.  
  214.  
  215.           
  216.  
  217.        
  218.       
  219.  
  220.  
  221.         
  222.  
  223.       
  224.  
  225.       
  226.  
  227.  
  228.  
  229.       
  230.