Re: CVS-19981211: PATCH for crash in fix-headers caused by cpplib.c

[Manfred Hollstein <manfred at s-direktnet dot de>]

On Mon, 14 December 1998, 08:07:22, zack@rabi.columbia.edu wrote:

 > On Mon, 14 Dec 1998 11:41:37 +0100 (MET), Manfred Hollstein wrote:
 > >On Sun, 13 December 1998, 02:00:35, law@hurl.cygnus.com wrote:
 > >
 > > >   > 1998-12-11  Manfred Hollstein  <manfred@s-direktnet.de>
 > > >   > 
 > > >   > 	* cpplib.c (do_include): Make sure "...->foundhere" is not
 > > >   > 	an ABSOLUTE_PATH before dereferencing it.
 > > > I don't see that this patch has been installed.
 > > > 
 > > > However, I also don't see fix header blowing up on my hppa2.0-hp-hpux10.20
 > > > build.  Any chance this bug was fixed by some other change?
 > >
 > >I don't think so.  This is what I got today without my patch applied:
 > [...]
 > 
 > Your patch points out a case I hadn't considered.  What should we do
 > when we see #include_next in a file included by an absolute path, or
 > in the primary source file?  (These are handled identically by
 > cpplib.)  Right now we dump core.  Your patch makes cpp give a "No
 > include path in which to find %s" error message.  Another possible
 > behavior would be to treat it as an ordinary #include.  I don't see an
 > obvious reason to prefer either of the two non-crashing behaviors.

Even if fixproto warns about:

  Various warnings and error messages from fixproto are normal

I believe, any proper error message like

  No include path in which to find xxx.h

would be better than the current

  ../../egcs-19981214/gcc/fixproto: line 257: 13773 Segmentation fault      (core dumped) $FIX_HEADER $rel_source_file $abs_source_file $abs_target_file ${DEFINES} $include_path

I didn't know, the crash was intentional, therefore I sent the patch.

manfred