jik@athena.mit.edu (Jonathan I. Kamens) (04/20/91)
In article <25835:Apr1908:41:2991@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |> While I'd love to pretend that most compilers ``out there'' are ANSI C |> (and UNIX and a VAX and...), I don't want to keep my code from working |> on the vast majority of implementations. I was under the impression that |> some environments either do not provide perror() or do not set errors in |> stdio; if perror() is universally available, I'll gladly recode the |> error messages around sprintf() and perror(). Judicious use of #ifdef's can allow a programmer to provide increased levels of support where it is possible to do so, while not providing such support otherwise. You already have a "sysconf" shell script in the sources. It seems trivial to me to put a test in it to compile a short test program to find out if perror() is useable on the current architecture, and if so, to define a symbol which will cause its use. You can even make it default to not using the new code, if it is unsure what to do. If you had sent yabbawhap to c.s.r, and I had been one of the reviewers, I would have asked you to add such error checking and reporting. In fact, I reviewed a package for c.s.r earlier this week, and the author failed to check some calls to fputs(), fclose(), etc. for errors, and I *did* ask him in my review to add such error checking and reporting. And so, Dan, it seems that perhaps c.s.r could have done something for your code after all. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710