Re: ../../gcc/fixproto[275]: 25412 Memory fault(coredump)

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> John David Anglin wrote:-
> 
> > Following up, the segfault occurs in a call to memcpy in cppfiles.c:
> > 
> >   /* Search directory path for the file.  */
> >   name = (char *) alloca (strlen (fname) + pfile->max_include_len
> > 			    + 2 + INCLUDE_LEN_FUDGE);
> >   for (path = search_start; path; path = path->next)
> >     {
> >       memcpy (name, path->name, path->len);
> > 
> > It appears that this is fallout from Zack's alloca patch (ie.,
> 
> No, I think it was my patch.  This is all related to basename ()
> not returning a pointer to within the string it was passed on
> your platform (and hence pointer subtraction returning a large
> random number).  Clearly, some input other than "", which I now
> catch as a special case, returns a special string too.

I know alloca caused the segmentation fault.  I printed path->name
and path->len in gdb and they were ok.  After defining USE_C_ALLOCA,
I got the huge malloc request.  This could be related to basename
as you suggest.  I quite looking last night before I had a definitive
answer.

The special cases for the XPG variant of basename are:

1) String ending in '/'.  The slash is stripped unless the string
   is all slashes in which case a pointer to "/" is returned.  Since
   the string can be modified, the argument of the XPG variant is
   char *.

2) Empty string and null string cause a pointer to "." to be returned.

The hpux manpage has this warning:

 WARNINGS
     The return value points to static data whose content is overwritten by
     each call.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)