Bug reported by Jon-Dean Mountjoy <csjm@cs.ru.ac.za>

Paul Kranenburg's description:
ld is in error here, assuming that symbols with N_EXT set always have an
entry in the (global) symbol table: this is not the case for C++ generated
constructor/destructor symbols. I can reproduce your failure by fudging
a "multiply defined" constructor symbol by hand. Checking for `g == NULL'
seems to be a ok as a fence for now.

So:
for now, in do_file_warnings() we check if g == NULL, before trying to generate
any warning messages.  This prevents a NULL pointer dereference.
This commit is contained in:
Geoff Rehmet 1994-06-14 12:45:41 +00:00
parent c4a6b5c74b
commit 86a13e77dd

View File

@ -1,5 +1,5 @@
/*
* $Id: warnings.c,v 1.5 1994/01/12 23:14:07 jkh Exp $
* $Id: warnings.c,v 1.6 1994/02/13 20:41:48 jkh Exp $
*/
#include <sys/param.h>
@ -621,6 +621,15 @@ do_file_warnings (entry, outfile)
g = entry->symbols[i].symbol;
s = &entry->symbols[i].nzlist.nlist;
/*
* XXX This is a temporary fence to correct an
* incorrect assumption made in the case of symbols
* which do not have entries in the (global)
* symbol table.
*/
if(g == NULL)
continue;
if (!(s->n_type & N_EXT))
continue;