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 / V144.DQC / V144.DOC
Text File  |  2000-06-30  |  6KB  |  133 lines
  1.  
  2.                           BDS C User's Guide Addenda
  3.                          v1.44 Edition --  April, 1981
  4.  
  5.                                   Leor Zolman
  6.                                   BD Software
  7.                                 33 Lothrop st.
  8.                         Brighton, Massachussetts 02135
  9.  
  10.  
  11.  
  12.      Actually,  I  managed  to  wipe out my only copy of the v1.44 update sheet
  13. when my hard disk crashed a little  while  ago,  but  I'm re-typing it from the
  14. hard copy just for placement into ar25:cpm;. Thus, the  entries  may  be  a bit
  15. more terse than the originals, but I think the info will still get across.  
  16.  
  17.      Here are the bug fixes/enhancements for version 1.44:  
  18.  
  19.  
  20. 1.   (v1.43a  only):  the  character  sequence \\ at the END of a quoted string
  21.      caused the preprocessor to screw up comment handling. For example, 
  22.      
  23.          printf("This backslash would cause bit trouble: \\");
  24.  
  25.      would have done it.  
  26.  
  27. 2.   The "qsort" function didn't work when  the  total  size  of the data array
  28.      being  sorted  exceeded  32K  bytes.  This has been fixed by changing  the
  29.      declarations  of  certain  variables  in  the   function   from  "int"  to
  30.      "unsigned".  
  31.  
  32. 3.   CC1,  CC2  and  CLINK  may  now  be  aborted  in  mid-execution  by typing
  33.      control-C.  
  34.  
  35. 4.   A new CLINK option, "-f", may be placed before a CRL filename to FORCE all
  36.      functions in that CRL file to be loaded immediately, regardless of whether
  37.      they have been referenced yet or not. The "-f" only affects one CRL  file,
  38.      and  the  next  file  mentioned is again only scanned for needed functions
  39.      (unless "-f" is used again.) 
  40.  
  41. 5.   The "rename" library function  had  a  rather  serious  problem:  whenever
  42.      executed, it would zero out the three bytes immediately following the  end
  43.      of  the  "rename" function in memory, thus wiping out the first jump table
  44.      vector of  the  next  function!  This  was  fixed  by  increasing the "ds"
  45.      statement at the end of the rename function (in deff2.asm)  from 49 to 53.
  46.  
  47. 6.   The  "setfcb"  function  requires  that  the buffer allocated to hold  the
  48.      resulting fcb is at least 36 bytes long (not  just  32  or  33.)...this is
  49.      because "setfcb" zeros out the random-record fields for CP/M  2.x, whether
  50.      or not they are needed.  
  51.  
  52. 7.   A character constant consisting of the double-quote character enclosed  in
  53.      single  quotes  ('"'),  caused CC1 to go haywire in the comment- stripping
  54.      phase.  
  55.  
  56. 8.   Whenever the "type" information  for a function definition was placed on a
  57.      line separate from the actual name  of  the  function,  the compiler would
  58.      "lose" one line number for error reporting, and all errors found past that
  59.      point in the file would be reported with an incorrect line  number.    For
  60.      example, the following text would have caused that problem:  
  61.      
  62.          char *
  63.          foo()
  64.          {
  65.              ...
  66.          }
  67.  
  68.  
  69. 9.   A  new library function, "execv", has been added to the package (source is
  70.      in DEFF2.ASM).  This  function  is  like  "execl",  except that a variable
  71.      number of parameters is passed by placing them into an array and passing a
  72.      pointer to the array instead of the actual parameters.  The  format of the
  73.      "execv" function is:  
  74.      
  75.          execv(prog,argvp)
  76.          char *prog, **argvp;
  77.  
  78.      where  `prog'  points  to  the  name  of the COM file to be executed,  and
  79.      `argvp'  is  an  `argv'-like  pointer to an  array  of  pointers  to  text
  80.      parameters. The final entry in  the  list  must  be  a null pointer. As an
  81.      example, note that the "execl" call 
  82.      
  83.          execl("stat","badspots","$r/o",0);
  84.  
  85.      may be written in terms of "execv" as follows:  
  86.      
  87.          char *args[3];
  88.          ...
  89.          args[0] = "badspots";
  90.          args[1] = "$r/o";
  91.          args[2] = NULL;
  92.          execv("stat",args);
  93.  
  94.      Pre-v1.45  version of the package contained an "execv"  that  printed  the
  95.      message "broken  pipe"  on the console and re-booted CP/M whenever "execv"
  96.      couldn't find the program  is  was  supposed to execute; v1.45 contains an
  97.      "execv" that simply returns -1 (ERROR)  when  the program cannot be found.
  98.  
  99. 10.  Directed I/O and pipes, of sorts, are now available  to BDS C programmers.
  100.      The  files  DIO.C  and DIO.H make up a cute little directed  I/O  package,
  101.      allowing for directed  input, directed output and pipes (a la Unix) on the
  102.      command line to programs  compiled  with this special I/O package. See the
  103.      comments in DIO.C for complete details.  Note  that  the  presence of this
  104.      package  does  NOT  contradict certain comments made in the BDS  C  User's
  105.      Guide about kludging  advanced  Unix  features  under CP/M; those comments
  106.      were directed toward systems in which the I/O redirected/generalization is
  107.      forced  upon  the user, along with all the entailing  overhead,  when  the
  108.      redirection isn't needed or wanted for many applications. The DIO package,
  109.      being written in  C and separately compiled, lets YOU decide when you want
  110.      it and when you do  not.  If you don't want it, it takes up zero space; if
  111.      you do, it takes up a  little  room and yanks in all the buffered I/O, but
  112.      it DOES give you redirection and pipes!  
  113.  
  114. 11.  a "standard error" buffered I/O  stream  number has been added to the list
  115.      of special devices recognized by the "putc"  buffered output function (and
  116.      thus all the buffered output functions that use  "putc"). An `iobuf' value
  117.      of 4 causes the character given to be written to the  CP/M console output,
  118.      always, while an `iobuf' value of 1 causes the character  to be written to
  119.      the standard output (which might be a file if the DIO package  is in use.)
  120.      Note  that  the  value  of  4  was chosed instead of 2 (the Unix standard)
  121.      because 2 was already taken to mean the CP/M lst: device.  
  122.  
  123. 12.  String constants may now contain zero bytes within them. Previous versions
  124.      have flagged lines such as 
  125.      
  126.          foo = "Jan\0Feb\0Mar\0Apr\0May\0Jun\0Jul\0Aug\0Sep\0Oct\0Nov\0Dec\0";
  127.  
  128.      with the error message:  
  129.      
  130.          Zero bytes are not allowed within strings; to print nulls, use \200
  131.  
  132. [END V144.DOC]
  133.