Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.unix.wizards
Subject: Re: too many enumerated types?
Summary: programs should use perror
Keywords: SystemV ld perror
Message-ID: <9218@bloom-beacon.MIT.EDU>
Date: 11 Feb 89 17:56:50 GMT
References: <435@laic.UUCP> <955@auspex.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Distribution: usa
Lines: 71

In article <435@laic.UUCP> scott@nova.laic.uucp (Scott Weitzenkamp) writes:
>I am having problems getting a 35000 line C program to link...
>...here's the error message I get when I try to link them:
>$ cc -g *.o
>ld fatal: fail to write symbol name LESSEQ_OP in string table 
>for file a.out

In article <955@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
>...the error message in question is printed if an "fwrite" of one symbol
>table entry fails to return 1.  The most likely causes of this are:
>		you ran out of disk space
>		you overflowed the stupid 1MB default file size limit
>	or	you got a real live I/O error

This example shows that the ld in question has violated one of
the cardinal rules* of error messages, and also nicely
illustrates the importance of these rules.  Had ld called
perror() or the equivalent**, the real reson for the error would
have been immediately evident, and Scott would not have been led
to his (reasonable, under the circumstances) misconception about
the number of enumerations.

                                            Steve Summit
                                            scs@adam.pika.mit.edu

* Briefly, the rules are:
     1.	always include the name of the program (ld got this right)
     2.	for errors related to system calls (including most
	stdio errors) always call perror
     3.	for errors that relate to a user file being read, always
	include the file name and line number

** perror() is less convenient than it could be for printing
   informative error messages.  You could call it with the name
   of the program, the name of the system call, or the name of
   the file being read, but not with all three.  Here is a simple
   routine I use to overcome these difficulties.  A sample use
   would be

	errorp("%s: error writing %s", progname, outfile);

   Note that errorp is varargs; be sure to declare it as

	extern void errorp(char *, ...);

   under an ANSI compiler.  Also note that it appends a newline;
   the format string shouldn't normally include one.

	#include <stdio.h>
	#include <stdarg.h>

	extern int errno;

	extern char *strerror();

	/* VARARGS1 */

	void errorp(fmt)
	char *fmt;
	{
	va_list argp;

	va_start(argp, fmt);
	vfprintf(stderr, fmt, argp);
	fprintf(stderr, ": %s\n", strerror(errno));
	va_end(argp);
	}

If you don't have an ANSI <stdarg.h>, you'll have to change it
slightly to use <varargs.h> (or, failing that, _doprnt).  If you
don't have strerror(), you can use sys_errlist[].