From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69495 invoked by alias); 11 Oct 2016 18:19:03 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 69478 invoked by uid 89); 11 Oct 2016 18:19:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=elsewhere, kerrisk, Kerrisk, risk X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com From: DJ Delorie To: Michael Kerrisk Cc: siddhesh@sourceware.org, libc-alpha@sourceware.org Subject: Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables In-Reply-To: (message from Michael Kerrisk on Tue, 11 Oct 2016 08:20:12 +0200) Date: Tue, 11 Oct 2016 18:19:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2016-10/txt/msg00209.txt.bz2 Michael Kerrisk writes: > I think the notion that because one does not document something, it's > not an official part of the ABI is at best highly dubious. I wasn't here for the origin of those variables, I'm just thinking that we use a leading underscore elsewhere to mean "not official" so the trailing underscore here might have similar intent. FTR I have no problem with documenting unsupported behavior, I just want to make sure we understand how this patch affects the officialness of this ABI. > The only way that documentation might be able to help in such > situations is where pieces are clearly and loudly documented right > from the beginning, in the official documentation, as "not supported, > may disappear at any moment in the future, use at your own risk", but > even then people are likely to ignore the documentation or be unaware > of it. That would be fine too. My concern is: if we intended for those variables to be unofficial before, do we want to (1) make them official now, or (2) be careful not to *accidentally* make them official? And if we decide they're official (and/or always have been), should we add in variants without underscores to be the official ones? So I guess the next step is to have someone in authority (or consensus?) decide if those variables are "official" or not, and if they should become so if not. Based on that we may want to tweak the documentation patch, or the code.