From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71212 invoked by alias); 22 Feb 2016 14:02:35 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 71186 invoked by uid 89); 22 Feb 2016 14:02:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=fuzzy, Hx-languages-length:1620, invite, contract X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx2.suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Date: Fri, 01 Jan 2016 00:00:00 -0000 From: Michael Matz To: Mark Wielaard cc: "H.J. Lu" , gnu-gabi@sourceware.org Subject: Re: Document existing GNU extensions In-Reply-To: <20160219225240.GF2586@blokker.redhat.com> Message-ID: References: <20160219225240.GF2586@blokker.redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2016-q1/txt/msg00003.txt.bz2 Hi, On Fri, 19 Feb 2016, Mark Wielaard wrote: > Not yet. But we should get one once we have concensus about how to make > sure we document things. > > I hope we can do it with minimal rules, just discuss any proposals to > document things on this list till there is concensus on the wording. > > I propose we invite the global maintainers of each of the GNU toolchain > projects (gcc, gdb, binutils and glibc) The global maintainers of at least GCC is a fuzzy definition ... > to appoint one reviewer/approver who is responsible for making sure ... and I think anyone interested in ABIs should meanwhile be aware of the existence of this list. > anything we document is actually a stable GNU gabi extension they are > willing to support (and not some accidental mistake that might seem to > work, but was never intented as public abi). Their job would simply be > to say "yes", "no" or "please, refer to another standard or project > documentation as official source" about any text we come up with that > has concensus. That way we make sure that what we document is actually > supported by the GNU toolchain projects for others to rely on. Well, as many of the things H.J. listed are effectively part of the dynamic linker/library/application contract they _are_ part of the ABI, and better be supportable for basically forever. So documenting existing behaviour, no matter if intended or accidental, seems worthwhile independend of anyone actually agreeing that the extension as is is "fine". That's of course different with any new proposed extensions. Ciao, Michael.