This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Antwort: Re: [plugins] [patch] Initial implementation of GCC plugin support
- From: Taras Glek <tglek at mozilla dot com>
- To: Markus Milleder <markus dot milleder at generali dot at>
- Cc: benjamin at smedbergs dot us, Basile STARYNKEVITCH <basile at starynkevitch dot net>, Cupertino Miranda <cupertinomiranda at gmail dot com>, Diego Novillo <dnovillo at google dot com>, gcc-patches at gcc dot gnu dot org, Grigori Fursin <grigori dot fursin at inria dot fr>, "Joseph S. Myers" <joseph at codesourcery dot com>, Le-Chun Wu <lcwu at google dot com>, Sean Callanan <spyffe at cs dot sunysb dot edu>, Zbigniew Chamski <zbigniew dot chamski at gmail dot com>
- Date: Tue, 24 Feb 2009 10:12:00 -0800
- Subject: Re: Antwort: Re: [plugins] [patch] Initial implementation of GCC plugin support
- References: <OFC8650E0E.3CD3D4FA-ONC1257567.003E9999-C1257567.00404D25@AT.TOP.COM>
Markus Milleder wrote:
Returning to my opening argument, I could only see risking breakage
if the plugin ensures that no binary is ever generated - e.g.
because it does some static analysis and then quits.
I like this idea. Perhaps we could block plugin loading based on
version+ mode tuple where mode would be either "readonly" or "modifies
stuff". We are really interested in the static analysis aspect of the
plugins and it makes sense to disallow this sort of behavior for a
plugin that will be modifying datastructures.
On the other hand, a memory corruption bug in a plugin could cause
memory corruption too, so users are playing with fire anyway.
Taras