🚀 go-pugleaf

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