From patchwork Wed Jul 5 13:48:27 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Joseph Myers X-Patchwork-Id: 21434 Received: (qmail 33282 invoked by alias); 5 Jul 2017 13:48:52 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 31154 invoked by uid 89); 5 Jul 2017 13:48:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS, URIBL_RED autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Date: Wed, 5 Jul 2017 13:48:27 +0000 From: Joseph Myers To: Zack Weinberg CC: Carlos O'Donell , GNU C Library Subject: Re: Updating NEWS for 2.26 In-Reply-To: Message-ID: References: <6aac1cbc-a1c8-5539-dc5e-c94c5d7353e5@redhat.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) On Wed, 5 Jul 2017, Zack Weinberg wrote: > On Tue, Jul 4, 2017 at 10:40 AM, Carlos O'Donell wrote: > > On 07/04/2017 10:36 AM, Zack Weinberg wrote: > >> > >> Given the variety of changes in this release I think some more > >> organization of NEWS would be helpful, as well. I'm thinking > >> subsections for changes to build requirements, new features, > >> deprecated and/or removed features, important bugfixes. > > > > Sure, I'll see what kind of logical groups the changes fall into. > > > > If you have a change in mind, please just checkin rough text and I'll > > wordsmith it later. > > This is done now; please feel free to make further changes as you see fit. Should we use those subject headings as standard for future releases? So, change the template for the NEWS section for a new release cycle at to include all those headings, on the basis that if a particular release doesn't have anything under one of the headings, we'll remove that section during the freeze. > I am wondering whether we really need a comprehensive list of all the > TS 18661-3 macros and functions. It's a giant wall of text and it may > make people think they're done reading, when the very important > "deprecated and removed features" section is just below. We should indicate in some way what the features are, at least, even without a full list. That is, a minimum is to indicate the general naming patterns (cf. the GCC 7 release notes, where I didn't try to give a full list of every possible macro or built-in function for these types, just to indicate the patterns); that they apply to all non-obsolescent interfaces that we have for long double, whether standard or not; that the support does not include those TS 18661-3 interfaces that aren't float128 versions of interfaces for other types. (We may not want to say specifically what exactly counts as obsolescent, but maybe note that there is no printf/scanf support for the type, with the strfromf128 / strtof128 functions being expected to be used instead.) I wonder if we should also mention the need for nondefault feature test macros to make these features visible, either _GNU_SOURCE or __STDC_WANT_IEC_60559_TYPES_EXT__. Also: there's a statement "Support for more architectures will be added in future releases.". I intend to enable support for _FloatN/_FloatNx functions in future *where they are aliases of functions for existing types*, but I'm still wary of making statements in NEWS about features to be added in future releases. I don't think support for float128 functions, specifically, is that likely to be added on more architectures where they aren't aliases for long double (the only glibc architecture with long double != float128, no float128 support in glibc, but float128 support in current GCC, is hppa, where the GCC float128 support exists but is for HP-UX only. (As noted in passing, I can envisage adding _Float16 support in future, which would be completely new function implementations, however.) I've applied this patch to say "GNU C Library" consistenly in NEWS items rather than the shorthand "glibc". diff --git a/NEWS b/NEWS index d54a3d6..5fbd0cf 100644 --- a/NEWS +++ b/NEWS @@ -19,19 +19,19 @@ Major new features: * Improvements to the DNS stub resolver, contributed by Florian Weimer: - - glibc will now detect when /etc/resolv.conf has been modified and reload - the changed configuration. The new resolver option “no-reload” - (RES_NORELOAD) disables this behavior. + - The GNU C Library will now detect when /etc/resolv.conf has been + modified and reload the changed configuration. The new resolver option + “no-reload” (RES_NORELOAD) disables this behavior. - - glibc now supports an arbitrary number of search domains (configured using - the “search” directive in /etc/resolv.conf); previously, there was a - hard limit of six domains. For backward compatibility, applications - that directly modify the ‘_res’ global object are still limited to six - search domains. + - The GNU C Library now supports an arbitrary number of search domains + (configured using the “search” directive in /etc/resolv.conf); + previously, there was a hard limit of six domains. For backward + compatibility, applications that directly modify the ‘_res’ global + object are still limited to six search domains. - - When the “rotate” (RES_ROTATE) resolver option is active, glibc will now - randomly pick a name server from the configuration as a starting point. - (Previously, the second name server was always used.) + - When the “rotate” (RES_ROTATE) resolver option is active, the GNU C + Library will now randomly pick a name server from the configuration as a + starting point. (Previously, the second name server was always used.) * The tunables feature is now enabled by default. This allows users to tweak behavior of the GNU C Library using the GLIBC_TUNABLES environment variable. @@ -167,7 +167,7 @@ Deprecated and removed features, and other changes affecting compatibility: removed. * Sun RPC is deprecated. The rpcgen program, librpcsvc, and Sun RPC headers - will only be built and installed when glibc is configured with + will only be built and installed when the GNU C Library is configured with --enable-obsolete-rpc. This allows alternative RPC implementations, such as TIRPC or rpcsvc-proto, to be used. @@ -178,8 +178,8 @@ Deprecated and removed features, and other changes affecting compatibility: The NIS(+) support library, libnsl, is also deprecated. By default, a compatibility shared library will be built and installed, but not headers or development libraries. Only a few NIS-related programs require this - library. (In particular, glibc has never required programs that use - 'gethostbyname' to be linked with libnsl.) + library. (In particular, the GNU C Library has never required programs + that use 'gethostbyname' to be linked with libnsl.) Replacement implementations based on TIRPC, which additionally support IPv6, are available from . The configure @@ -247,15 +247,15 @@ Changes to build and runtime requirements: supported by that kernel. (This is a change from version 2.25 only for x86-32 and x86-64.) -* GNU Binutils 2.25 or later is now required to build glibc. +* GNU Binutils 2.25 or later is now required to build the GNU C Library. -* On most architectures, GCC 4.9 or later is required to build glibc. On - powerpc64le, GCC 6.2 or later is required. +* On most architectures, GCC 4.9 or later is required to build the GNU C + Library. On powerpc64le, GCC 6.2 or later is required. Older GCC versions and non-GNU compilers are still supported when - compiling programs that use glibc. (We do not know exactly how old, - and some GNU extensions to C may be _de facto_ required. If you are - interested in helping us make this statement less vague, please + compiling programs that use the GNU C Library. (We do not know exactly + how old, and some GNU extensions to C may be _de facto_ required. If you + are interested in helping us make this statement less vague, please contact libc-alpha@sourceware.org.) Security related changes: