home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Interactive Guide / c-cplusplus-interactive-guide.iso / c_ref / csource3 / 106_01 / stdio.doc < prev    next >
Encoding:
Text File  |  1980-07-09  |  3.5 KB  |  71 lines
  1.     stdio.doc, an attempt to explain things.
  2.  
  3.     The files that I've sent to the BDS C user's group include the
  4.     early versions of the code I used for simulating the UNIX facility
  5.     for invisible redirection of STDIN and STDOUT files. These
  6.     are not a finished product by any means, and you MUST understand
  7.     their operation to use them sucessfully!
  8.  
  9.     A little history will help. The first version of stdio was written
  10.     before I had recieved the 1.32 (or 1.31+) version of the BDS
  11.     software, and before I decided to rewrite most of the I/O
  12.     functions. I have since been sidetracked and otherwise occupied,
  13.     so that neither of these interlocked projects is completed, and I
  14.     cannot honestly attempt to guess just when such completion may
  15.     occur. So. The files I sent are believed to be the final version
  16.     of the original effort, and will certainly suffice to demonstrate
  17.     the concept I used. BUT...I had a disk blowup and am not entirely
  18.     positive that the files I sent are the files that I was using!
  19.     So proceed with caution.
  20.  
  21.     The primary thing to watch for when using these functions is...
  22.     The stdio routines need some static variables that can be accessed
  23.     by both stdopen and stdclose. In the BDS version of C, that means
  24.     they must be GLOBALS. This is a little bit messy, and there are
  25.     two approaches that could be used.
  26.  
  27.     1)    include the stdio functions and the global declarations
  28.         in the source of every program that uses them
  29.  
  30.     2)    include (as the VERY FIRST globals) the definitions of the
  31.         variables in each source file that will use the functions
  32.  
  33.     I chose approach 2. The included file (in the early version) is
  34.     called "stdio.lib", and contains the declarations for the globals
  35.     needed by the stdopen and stdclose routines. This has the advantage
  36.     of letting the source for the stdio routines be compiled seperately
  37.     and put into a library. On the other hand, it also means that it is
  38.     YOUR resposibility to remember to include the definitions, because
  39.     the error will not be detected until the program blows up if you
  40.     forget.
  41.  
  42.     I later incorporated the stdio declarations into my standard header
  43.     file (called "c.h"), which contains all sorts of standard definitions
  44.     that I use, which minimizes the possibility of forgetting them. But
  45.     I still had to re-compile quite a few programs before I felt I was
  46.     quite safe.
  47.  
  48.     See also the documentation header in the stdio.src file.
  49.  
  50.     To sum it all up: the files distributed are believed to be correct
  51.     working versions, and should behave properly. But there just might
  52.     be a symbol name or two that has gotten changed in one of the files
  53.     but not in another, or some other similar little glitch. So be sure
  54.     that you understand what's going on, and be careful.
  55.  
  56.     If and when I complete the package, I'll send the whole mess to
  57.     our user's group. But I really can't say when that will happen,
  58.     which is the reason I submitted this interim version.
  59.  
  60.                     Good computing!
  61.                     Marty Maney
  62.  
  63.     postscript:
  64.     Since writing the above, I found an old listing of the stdio file.
  65.     It seems that the names of a few defined constants may have changed,
  66.     and I think that the default initialization of _stdin & _stdout
  67.     that is in the .src file may not be correct (for the stock versions
  68.     of getc & putc). Other than that, it looks like they're OK, but
  69.     I still think you should go over them before using them. It can't
  70.     hurt, and could prevent some anguish.
  71.