home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / CPM / BDSC / BDSC-3 / V143.DQC / V143.DOC
Text File  |  2000-06-30  |  9KB  |  192 lines
  1.  
  2.                           BDS C User's Guide Addenda
  3.                          v1.43 Edition --  March, 1981
  4.  
  5.                                   Leor Zolman
  6.                           BD Software  (New Address!)
  7.                                 33 Lothrop st.
  8.                               Brighton, Ma. 02135
  9.                                 (617) 782-0836
  10.  
  11.  
  12.  
  13.      Here are the bugs found and fixed for v1.43, and some additional notes:  
  14.  
  15.  
  16. 0.   Another   logical-expression-related  bug  caused  incorrect  code  to  be
  17.      generated when  a  subexpression  of  a binary operation used the && or ||
  18.      operators. For example, 
  19.      
  20.              if (x > (i==5 && j<7)) printf("Foobar\n");
  21.  
  22.      might have caused a crash when executed.  
  23.  
  24. 0.5  A bitwise or arithmetic binary operation  in which the left argument was a
  25.      logical  expression  of  any  kind and the right  argument  was  a  binary
  26.      expression of higher precedence failed to evaluate correctly. For example,
  27.      
  28.          if (!kbhit() & a<5) printf("foo\n");
  29.  
  30.      didn't work.  
  31.  
  32. 1.   A missing comma, such as in the statement:  
  33.      
  34.              sprintf(dest "x = %d\n", x);
  35.  
  36.      went undiagnosed and caused wierd  code to be generated. (The bug fixed in
  37.      the last release had only corrected  the  case  of a missing comma AFTER a
  38.      format string specification, not BEFORE it...) 
  39.  
  40. 2.   If  a  comment  was  begun  on  a  line  which  contained   an  "#include"
  41.      preprocessor  directive, and not terminated until a later line,  then  CC1
  42.      became confused.   2a.  Several users have complained about not being able
  43.      to put the character  sequence  `/*'  into  a  quoted  string.  This  is a
  44.      justifiable gripe, but I'm afraid you'll have to say things like "/\*"  to
  45.      get  the  same  effect.  The  reason  comment delimiters are not tolerated
  46.      within quotes 
  47.  
  48. 3.   Mismatched  curly-braces  in a source file  now  draw  a  more  meaningful
  49.      diagnostic  than the previous  "Unexpected  EOF  encountered"  message:  a
  50.      pointer is now  provided  to the line at which the badly-balanced function
  51.      begins.  
  52.  
  53. 4.   When an illegal constant was  encountered  by  CC1  at  any  place where a
  54.      constant is required, an incorrect "Unmatched left parenthesis" diagnostic
  55.      was displayed with an impossibly large line number. (Actually, the correct
  56.      line number was obtainable by subtracting the exact size of the  text file
  57.      from  the  given  line  number.  Guess what I forgot to initialize between
  58.      passes...) 
  59.  
  60. 5.   When using the "-w" option with CLINK, a terminating control-Z was NOT put
  61.      out to the SYM file when the length  of  the  SYM file worked out to be an
  62.      exact multiple of 128 bytes. This gave CLINK a headache when "-y" was used
  63.      to read the SYM file back in.  
  64.  
  65. 6.   There  was  another bug in the "getc" library function  that  caused  some
  66.      trouble when  the  "fgets"  function was used to read in lines from a text
  67.      file that wasn't terminated with  control-Z  (CPMEOF).  This  was fixed by
  68.      changing the line:  
  69.      
  70.              return ERROR;
  71.  
  72.      to:  
  73.      
  74.              return iobuf->_nleft++;
  75.  
  76. 7.   Mismatched  square brackets in an expression had drawn an "Unexpected  EOF
  77.      encoutered" error instead of something more meaningful.  
  78.  
  79. 8.   The word "main"  is  NO  LONGER  A KEYWORD. In previous versions, the fact
  80.      that "main" was treated as a keyword  made  its use in any situation other
  81.      than as the first line of a "main" function impossible.  I.e,  attempts to
  82.      call "main" recursively were not accepted by the compiler. There is now no
  83.      longer  anything  special  about  the  word  "main". In addition, previous
  84.      versions had substituted an undocumented one byte  code  (9D  hex) for the
  85.      name  "main"  in CRL file directories, thereby probably causing a  lot  of
  86.      confusion. This bizarre scheme is no longer used, although the linker will
  87.      still recognize  the special 9D code as meaning "main" when encountered in
  88.      a CRL file (of course, "MAIN" will now also be recognized...) 
  89.  
  90. 9.   A bug in the "-y" option handler in CLINK caused CLINK to crash when there
  91.      wasn't enough room  in  the  reference table to hold all the symbols being
  92.      read in from a SYM file. Sorry  about  that, chief. Note, by the way, that
  93.      the POSITION of "-y" on the command line  IS VERY SIGNIFICANT. If the "-y"
  94.      option appears to the right of names of CRL  files to search, then the SYM
  95.      file specified will not be used until AFTER the  previous  CRL  files have
  96.      already been scanned and loaded from. I.e., the "-y" option should  appear
  97.      BEFORE  the  names  of any CRL files that contain functions that might not
  98.      need to be loaded (due to their definition in the SYM file). A new feature
  99.      of CLINK is that whenever  a  previously  defined symbol is encountered in
  100.      the process of loading the symbols from a SYM  file,  a  message  to  that
  101.      effect  will be printed, allowing the user an opportunity to rearrange the
  102.      command line  so  that the SYM file is read in earlier and some redundancy
  103.      possibly eliminated.  
  104.  
  105. 10.  An obscure feature  of  the  "printf",  "sprintf"  and  "fprintf"  library
  106.      functions,  as  described  in  the  Kernighan  &  Ritchie  book, is that a
  107.      field-width specification value preceded by a '0' caused 0-fill instead of
  108.      space-fill. I'd never NOTICED that before, until a user brought  it  to my
  109.      attention  (and  conveniently  provided  a  fix.)  Note that this solves a
  110.      problem  often encountered when printing hex values.  Now,  the  following
  111.      "printf" call:  
  112.      
  113.              printf("%4x; %04x\n",8,8);
  114.  
  115.      will produce the output:  
  116.      
  117.                 8; 0008
  118.  
  119. 11.  The body of  a  function  definition now MUST be enclosed in curly-braces.
  120.      Formerly,  the  following sort  of  thing  was  tolerated  as  a  function
  121.      definition, but no more:  
  122.      
  123.              putchar(c) bdos(4,c);
  124.  
  125. 12.  A bug in the CMAC.LIB macro package had NOT allowed lines such as:  
  126.      
  127.              exrel <lxi h,>,putchar
  128.  
  129.      while the following kind of lines were properly handled:  
  130.      
  131.              exrel call,putchar
  132.  
  133. 14.  Quoted strings containing an open-comment  delimiter  sequence  (`/*') had
  134.      caused CC1 to think an actual comment was intended. I.e, the statement 
  135.      
  136.          printf("this is an open-comment sequence: /* \n");
  137.  
  138.      would have drawn a "string too long..." error. Not any more.  
  139.  
  140. 15.  The  handling of string constants by the code generator has been improved.
  141.      Now, instead  of  putting the text right where it is used and generating a
  142.      jump around it, the  compiler  accumulates  up  to  50  text  strings in a
  143.      function and places them all at the end of the function. If more  than  50
  144.      strings  appear,  then after the 50th it goes back to doing it the old way
  145.      for the remainder of  the function (there's only so much table space worth
  146.      allocating to hacks like this.) 
  147.  
  148. 16.  Speaking of hacks, here's one that'll get you either excited or sick:  You
  149.      say you need some "static"  variables?  Consider  the  following method of
  150.      simulating a "static array of characters":  
  151.      
  152.              char *static;
  153.              ...
  154.              static = "0123456789";
  155.              ...
  156.  
  157.      The result is that the variable "static" may be used just  like  a  static
  158.      array  of ten characters. If declared as an "int" instead of a "char",  it
  159.      could be  used  as an array of five integer variables (or ten, if you make
  160.      the quoted string  twice  as  long...).  Steve  Ward  makes  use  of  this
  161.      technique in his CIO.C library. Kludgey, yes, but it gets the job done and
  162.      it's even portable...  
  163.  
  164. 17.  The  default  CC1  symbol table size for modified versions of the compiler
  165.      (v1.43T) has been upped  from  6K  to  7K.  The "-r" option still lets you
  166.      explicitly set the table allocation, if you want to.  
  167.  
  168.  
  169. 19.  The BDS C User Group has moved. John Nall  down  in  Florida  is no longer
  170.      coordinating  it;  please  don't send anything more his way. The new  User
  171.      Group address is:  
  172.      
  173.              Robert Ward
  174.          BDS C User's Group
  175.               PO Box 287
  176.              Yates Center, Kansas 66783
  177.              (316) 625-3554
  178.  
  179.      Many thanks are due John Nall  for  starting the Group and putting much of
  180.      his effort into getting it going; also  to  thank  are  all  you users out
  181.      there  who've  contributed  original software to the Group and offered  to
  182.      help  in  distribution and paperwork,  and  of  course  everyone  who  has
  183.      expressed enough interest in the Group to at least get on the mailing list
  184.      has also helped  boost  interest. Contributions and requests should now be
  185.      sent to Robert Ward;  The  disks  he'll  be  distributing may be charged a
  186.      little for, but I'm sure it'll be worth it in terms of providing the Group
  187.      an incentive to keep on going. Note that the BDS  C  User  Group routinely
  188.      provides  updates of BDS C to bona fide owners at rates considerably  more
  189.      economical (i.e., a heck of a lot CHEAPER) than anywhere else.  
  190.  
  191. [END V143.DOC]
  192.