From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32059 invoked by alias); 15 Oct 2002 19:15:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 32049 invoked from network); 15 Oct 2002 19:15:15 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sources.redhat.com with SMTP; 15 Oct 2002 19:15:15 -0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.10) id 181X9v-00033V-00 for gcc@gnu.org; Tue, 15 Oct 2002 15:15:15 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 181X9o-0003YS-00 for gcc@gnu.org; Tue, 15 Oct 2002 15:15:10 -0400 Received: from piper.synopsys.com ([146.225.1.217]) by monty-python.gnu.org with esmtp (Exim 4.10) id 181X9n-0003XR-00 for gcc@gnu.org; Tue, 15 Oct 2002 15:15:07 -0400 Received: (from jbuck@localhost) by piper.synopsys.com (8.11.6/8.11.6) id g9FJF5I22148; Tue, 15 Oct 2002 12:15:05 -0700 From: Joe Buck Message-Id: <200210151915.g9FJF5I22148@piper.synopsys.com> Subject: Re: XML dumping and GraphViz/VCG in the GCC ast-optimizer-branch To: mdupont777@yahoo.com (James Michael DuPont) Date: Tue, 15 Oct 2002 13:13:00 -0000 Cc: Joe.Buck@synopsys.COM (Joe Buck), gcc@gnu.org In-Reply-To: <20021015180452.73666.qmail@web13303.mail.yahoo.com> from "James Michael DuPont" at Oct 15, 2002 11:04:52 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 X-Spam-Level: X-SW-Source: 2002-10/txt/msg00856.txt.bz2 > Now, if we look at the problem of communication, how can the gcc safely > communicate the asts to the vcg for layout. You'll have to assume, I think, that anything gcc can write anyone can use. > Now, I am not a laywer, but > I think that if we can show that if the data is put into such a form > that it is indended for transport between modules, and a third party > takes that data a runs off with it, we can then say that they got > between two statically linked modules . Maybe that will offer some > protection against non-free modules getting in between? I think it would be hard to make such an argument if what is communicated is basically just information about the structure of the user's own code. But this list is not the best place for such discussions.