Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!rice!uupsi!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.sources.d
Subject: Re: v01INF1: Status - Status of comp.sources.reviewed
Message-ID: <25835:Apr1908:41:2991@kramden.acf.nyu.edu>
Date: 19 Apr 91 08:41:29 GMT
References: <1991Apr16.131650.24389@scuzzy.in-berlin.de> <1307:Apr1702:20:0991@kramden.acf.nyu.edu> <FUSA56C@xds13.ferranti.com>
Organization: IR
Lines: 17

In article <FUSA56C@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
> In article <1307:Apr1702:20:0991@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> > but I didn't want to sacrifice portability just to get UNIX error
> > messages. I welcome suggestions for how to solve this.
> How does calling "perror" sacrifice portability? Any compiler that doesn't
> include a functioning perror() in their standard I/O library isn't worth
> supporting... it's probably got other major limitations even if it satisfies
> the letter of the ANSI C standard.

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().

---Dan