From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68277 invoked by alias); 12 Oct 2016 11:57:57 -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 68252 invoked by uid 89); 12 Oct 2016 11:57:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_NEUTRAL autolearn=no version=3.3.2 spammy=H*RU:sk:homiema, HX-HELO:sk:homiema, H*M:aad1, H*r:sk:homiema X-HELO: homiemail-a92.g.dreamhost.com Reply-To: siddhesh@sourceware.org Subject: Re: [PATCH 1/2] Add note on MALLOC_MMAP_* environment variables References: To: DJ Delorie , Michael Kerrisk Cc: libc-alpha@sourceware.org From: Siddhesh Poyarekar Message-ID: <0d8de2e2-aad1-0819-a9dc-7f70c97bf798@sourceware.org> Date: Wed, 12 Oct 2016 11:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00218.txt.bz2 On Tuesday 11 October 2016 11:48 PM, DJ Delorie wrote: > 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. I agree, that may have been the intent. However what happened afterwards (i.e. their widespread use and the lack of communication to the contrary from the then maintainers) have invalidated that intent IMO. What's more, other important sources (the man pages, Red Hat product documentation) document these environment variables and that gives them as much a sense of credibility as anything else. > And if we decide they're official (and/or always have been), should we > add in variants without underscores to be the official ones? I'll be adding in tunables, which would become the 'official' versions of these envvars. Tunables come with the disclaimer that they may disappear/reappear in releases, but I don't think we will do that for the malloc tunables in practice. > 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. It is usually consensus. Siddhesh