Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.sprintlink.net!wizard.pn.com!mozo.cc.purdue.edu!purdue!haven.umd.edu!news.umbc.edu!cs.umd.edu!not-for-mail
From: torek@elf.bsdi.com (Chris Torek)
Newsgroups: comp.unix.bsd.bsdi.misc
Subject: Re: tis toolkit compile problems....
Date: 28 Sep 1995 02:46:54 -0700
Organization: Berkeley Software Design, Inc.
Lines: 37
Message-ID: <44dque$pqi@elf.bsdi.com>
References: <449ru3$su7@gateway.gallup.com> <44c4jc$ho5@web1.bga.com>
Reply-To: torek@bsdi.com
NNTP-Posting-Host: elf.bsdi.com
In article <449ru3$su7@gateway.gallup.com> Todd Beebe <todd@gallup.com> notes:
>http-gw.h:21: conflicting types for sys_errlist
Vick Khera and David P. Maynard both note that this problem can
always be fixed by deleting (or using `#ifndef __bsdi__' around)
the program's declaration(s) of sys_errlist[].
It is probably worth adding that the `right' fix is to remove all
references to sys_errlist[] entirely. They will either be
declarations, which can simply be deleted, or uses like:
printf("something went wrong: %s\n", sys_errlist[errno]);
The ANSI/ISO C Standard requires systems to provide a strerror()
function that produces the appropriate text, so that the above
should read:
printf("something went wrong: %s\n", strerror(errno));
This has the advantages of (a) working on all ANSI-conformant
systems and (b) doing something reasonable when errno is something
unexpected, such as when an old binary is run on a future system
with new error numbers.
Software that must run on systems that fail to provide a strerror()
can still use strerror(), by including an optional `strerror.c'
module (with the obvious code) for these systems. (Thus, if someone
says `not all systems have strerror()', that is not a good excuse. :-) )
For strict correctness, any source module that uses strerror() should
also `#include <string.h>'. (The -Wimplicit warning flag for gcc2
will detect missing declarations of this sort. See gcc(1) for details.)
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
Berkeley, CA Domain: torek@bsdi.com +1 510 549 1145
`... if we wish to count lines of code, we should not regard them as
``lines produced'' but as ``lines spent.'' ' --Edsger Dijkstra