Re: PATCH: better cpplex.c patch

[Greg McGary <greg at mcgary dot org>]

Jeffrey A Law <law@cygnus.com> writes:

> The problem is see is that include/bounded-ptr.h will also be installed by
> (for example) a binutils or gdb install.

That's OK.

> [ Remember, while we don't 
> necessarily share a repo with gdb/binutils, include & libiberty are virtually
> shared across several projects).

Yes, I know.

> This could cause us to pick up the include/ version instead of the GCC 
> wrapper version.  Won't that cause problems?

No, I think not.  Any number of wrappers in the include search path
are OK.  When not using BPs, the first wrapper will define the stubs
and that will be the end of it.  When using BPs, each wrapper will
#include_next until we finally reach the installed gcc/ginclude
version that has the non-stub macros.

> Is there some reason why we need two bounded-ptr.h files?  Why can't we
> have one which always does the right thing?

The gcc/ginclude/ version is intended to be installed with a
BP-capable gcc.  It provides macros that are useful to a user of the
installed BP-capable gcc who passes `-fbounded-pointers' during use.
The include/ version is a compatibility wrapper for a package that is
BP-ready but wishes to be portable with compilers that don't support
BPs.  The confusion comes from gcc being both (1) a supplier of the BP
feature (gcc/ginclude), and (2) a package that can be compiled with
`-fbounded-pointers' provided a BP-capable compiler is available.

Some packages never need any of the macros in bounded-ptr.h, so they
need not supply the wrapper bounded-ptr.h.

> I also see a number of GNU C extensions in that file.

I assume you refer to the gcc/ginclude version.  Note that the
guts of that file are inside `#if __BOUNDED_POINTERS__'.  These
macros depend on gcc and on details of the BP implementation in
gcc.  They freely use gcc extensions because they only make sense
when used in conjuction with `gcc ... -fbounded-pointers'.

> Might it be good to
> make sure it's not being compiled with a compiler other than GCC?  

A user would need to make extra effort to define __BOUNDED_POINTERS__
in order to get the non-stub definitions.  By default, the stubs are
defined, which is what we want for older gcc and non-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
> up-to-date version.

For the past several months, gcc has accepted `-fbounded-pointers' on
the command line, but it essentially does nothing.  Of note for this
case is that the cpp specs that cause __BOUNDED_POINTERS__ to be
defined don't exist, so again someone would need to explicitly define
__BOUNDED_POINTERS__ in order to get the non-stub definitions.

Still, it's probably a good idea to #if on compiler version if for no
other reason than as documentation.

If you have better ideas for how to supply BP-assist macros in a way
that is convenient and backward compatible with older gcc and non-gcc,
I'll happily receive them.

Greg