Hello All
See also my message http://gcc.gnu.org/ml/gcc/2010-09/msg00270.html
about plugin hooks for plugin-provided builtins?
I was thinking of adding a new plugin hook for plugin-provided
additional macros.
The intuition is that some plugins would be delighted if they could
add their own predefined macros, like __COUNTER__.
I imagine several use cases for such a feature, such as:
* we could have a plugin providing a __RANDOM__ macro wich would be
expanded at cpp expansion time into a random number.
* we could have a plugin provided __COMPILE_SYSTEM__ macro which
would expand to a string (e.g. like the one given by the uname -a
command) detailing the system on which GCC is running.
* we could even have a __RANDOM_UPTO__(N) unary macro [with one
argument] which would be expanded to a random number up to N
(which should be a preprocessor constant). So a call to
__RANDOM_UPTO__(64) would generate a random number between 0 and
63 included, and a call to __RANDOM_UPTO__(100) would generate a
ranom number between 0 & 99
* we could have a __PRIME_NUMBERS_UPTO__(N) macro which would be
expanded by all the prime numbers up to the constant N, with
commas. So the user would just code
int my_table_of_primes[] = { __PRIME_NUMBERS_UPTO__(10000) };
* this is definitely extreme and I won't do that, but we could even
imagine -just for the example- our gengtype being implemented by
a complex plugin. Then GTY would be an attribute handled by that
plugin, and #include "gt-foo.h" would be perhaps replaced by a
__INCLUDE_GENGTYPE_CODE__ here macro which would include all the
code gengtype currently is generating.
We could even imagine that some plugins would extend the existing CPP
directives. For instance, in
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01050.html I suggested a
#pragma GCC startsamelines but we could have it a #samelines directive
provided by a plugin. And we could imagine a plugin running popen
instead of fopen for #pinclude; I do know that open a lot of security
risks, but I also have many useful usage cases for that; for example
#pinclude "echo const char mysystem[] = \"`uname -a`\";"
My current thinking is that
1. we should provide before end of stage 1 for 4.6 hooks for simple
predefined macros without arguments like __RANDOM__ or
__COMPILE_SYSTEM__. Maybe we should restrict these to some common
prefix, like __GCCPLUGIN__RANDOM__ or
__GCCPLUGIN__COMPILE_SYSTEM__. I would imagine it is not very
difficult: After having provided registration facilities to plugins,
I was thinking of extending _cpp_builtin_macro_text from
libcpp/macro.c and providing hooks in cpp_init_special_builtins etc.
2. I have no clear idea about plugin specific predefined macros with
arguments, like __RANDOM_UPTO__(N) unary macro above. What are the
issues in implementing that?
3. Plugins should probably not be able to add CPP directives like
#pinclude etc.. but we should make sure that the same is achievable
using plugin provided #pragma-s. Is it really the case? Are
#pragma-s handled by libcpp somehow? Can the current trunk achieve
the goals of #pinclude thru a pragma provided by a plugin?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
