Mail Archives: djgpp-workers/2004/07/09/11:53:26
On Wednesday 07 July 2004 06:27, you wrote:
> Neil Booth <neil AT daikokuya DOT co DOT uk> writes:
> > Zack Weinberg wrote:-
> >
> >> Andris Pavenis <pavenis AT latnet DOT lv> writes:
> >> > found:
> >> > + /* pfile->file_hash may have been modified if -remap is specified
> >> > */ + if (CPP_OPTION (pfile, remap))
> >> > + hash_slot = (struct file_hash_entry **)
> >> > + htab_find_slot_with_hash (pfile->file_hash, fname,
> >> > + htab_hash_string (fname),
> >> > + INSERT);
> >>
> >> So neither I nor - as far as I know - *anyone* really understands this
> >> data structure, but I'm pretty sure this is wrong. You're causing it
> >> to store the cached entry under the remapped name, where it will never
> >> be found on lookup.
> >
> > I don't see why you think it's the remapped name. fname is local
> > to the subroutine. I expect the patch is OK, but...
>
> Oops, I misread it. Well, it's still wrong; -remap has no business
> doing anything that would invalidate the hash slot -- both because
> it's a layering violation, and because doing another INSERT operation
> before the previous slot is filled will leave the htab structure in an
> inconsistent state.
>
> Hmm. We have pfile->cb.missing_header now. Could we possibly
> leverage that to get the -remap "feature" out of files.c and into a
> djgpp-specific file in gcc/config, where at least it isn't causing
> trouble for anyone else?
It is not causing trouble for others unless option -remap is used.
Use of cb.missing_handler will break order of search of include files. Name of
file may be remapped to fit DOS filename limitations. Not remapped name could
be still valid when running in DOS session for example under Windows 98. So
as result it's possible to get wrong file included in this case.
> Andris, are you willing to try to do that?
I think, the best could be to reimplement remap_filename() to avoid use of
pfile->file_hash in it.
Andris
- Raw text -