toma@tekgvs.LABS.TEK.COM (Tom Almy) (11/17/89)
Well as if the problem of binary versus ascii files weren't enough, I've now discovered a *major* problem with console versus file (or other device) io. The functions xlgetc() and xlputc() are used to read and write streams. If the stream is a filestream, and if the file pointer is stdin (for xlgetc) or stdout or stderr (for xlputc), then the functions ostgetc/ostputc are used, rather than "standard" fget and fput. Ostgetc provides line editing functions. Ostputc provides transcript output. In addition, a routine in the compiler dependent file attempts to read from stdin during the execution of eval in order to allow interruption of execution. Now if stdin is redirected to come from a file (done on the command line) then eval will suck characters out of the input stream (*VERY BAD*). If the *Standard-Input* and/or *Standard-Output* symbols are assigned explicitly to the console, in MS/DOS this would be (setq *Standard-Input* (open "con" :direction :input)) for instance, then the program will fail to realize that the terminal stream is being used, and will not use the ost* functions! There is another problem. Imagine the case where *standard-output* is reassigned to some file stream. With the next garbage collect, stdout gets closed! The next time a file is opened, the same file slot will be used (at least with some stdio implementations), and that file will now be treated (by xlisp) as a console! Well it looks like a terrible mess to me. Any suggestions? My current feelings is to document it as a feature! The last problem is easily fixed by having sweep() not close stdin, stdout, or stderr. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply