This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: better cpplex.c patch
- To: Greg McGary <greg at mcgary dot org>
- Subject: Re: PATCH: better cpplex.c patch
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 14 Sep 2000 17:16:06 -0600
- cc: gcc-patches at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <email@example.com>you write:
> Jeffrey A Law <firstname.lastname@example.org> writes:
> > The whole patch please -- including Makefile.in changes, the ChangeLog en
> try, etc.
> 2000-09-14 Greg McGary <email@example.com>
> * bounded-ptr.h: New file.
> * Makefile.in (BOUNDED_PTR_H): New variable.
> (ggc-page.o, cpplex.o): Depend on $(BOUNDED_PTR_H).
> * cpplex.c (_cpp_expand_name_space): Use RELOCATE_POINTER_INCR_HIGH.
> (parse_number, parse_string, save_comment): Use SET_BOUNDS.
> * ggc-page.c (ggc_alloc): Use SET_BOUNDS.
> * ginclude/bounded-ptr.h: New file.
The problem is see is that include/bounded-ptr.h will also be installed by
(for example) a binutils or gdb install. [ Remember, while we don't
necessarily share a repo with gdb/binutils, include & libiberty are virtually
shared across several projects).
This could cause us to pick up the include/ version instead of the GCC
wrapper version. Won't that cause problems?
Is there some reason why we need two bounded-ptr.h files? Why can't we
have one which always does the right thing?
I also see a number of GNU C extensions in that file. Might it be good to
make sure it's not being compiled with a compiler other than GCC?
Similarly it seems as if you also need to check the GCC version number of
some such to ensure that if you're compiling with GCC that it is a suitably