Message ID | alpine.DEB.2.20.1707051333280.31495@digraph.polyomino.org.uk |
---|---|
State | New |
Headers | show |
On Wed, Jul 5, 2017 at 9:48 AM, Joseph Myers <joseph@codesourcery.com> wrote: > > 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 > <https://sourceware.org/glibc/wiki/Release> 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 would like to see that happen, yes. >> 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. [...] I think that most of what you describe is too much detail for someone reading NEWS, who wants one- or two-sentence summaries of _all_ the new features, not a dive on any one particular feature. It would be better to relegate all of this verbiage about TS 18661-3 to a separate file that would be progressively updated as support for it becomes more complete. (I'd suggest a top-level FLOAT128 file but that would exacerbate the existing problem of top-level ALLCAPS files where it's unclear how old it is and whether it's even vaguely relevant to the present release.) > 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 Hmm, I didn't know that. Please go ahead and take that statement back out, then. > I've applied this patch to say "GNU C Library" consistenly in NEWS items > rather than the shorthand "glibc". I don't like this; it sounds pompous and makes several sentences harder to read. For instance > - - 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. changing this from a simple noun to a noun phrase means that an already-complicated sentence now has a garden-path problem as well. zw
On Wed, 5 Jul 2017, Zack Weinberg wrote: > >> 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. [...] > > I think that most of what you describe is too much detail for someone > reading NEWS, who wants one- or two-sentence summaries of _all_ the > new features, not a dive on any one particular feature. It would be > better to relegate all of this verbiage about TS 18661-3 to a separate > file that would be progressively updated as support for it becomes > more complete. I think the appropriate length depends on the size of the feature. Typically we'd expect to list the new interfaces (which may sometimes be quite a long list, e.g. the TS 18661-1 functions in 2.25), but in this case a briefer description in terms of how they relate to existing features for other types should suffice. > (I'd suggest a top-level FLOAT128 file but that would exacerbate the > existing problem of top-level ALLCAPS files where it's unclear how old > it is and whether it's even vaguely relevant to the present release.) I think in general those files should be avoided and merged into other documentation etc. where possible - the manual already documents the individual float128 interfaces. > > I've applied this patch to say "GNU C Library" consistenly in NEWS items > > rather than the shorthand "glibc". > > I don't like this; it sounds pompous and makes several sentences > harder to read. For instance It's previously been stated that the manual (as opposed to comments) should not use abbreviations such as "glibc" or "GNU libc". I'd consider NEWS entries as formal documentation like the manual. https://sourceware.org/ml/libc-alpha/2012-02/msg00539.html Entries that are not about e.g. building glibc as a whole could reasonably say something like "the resolver" instead.
On Wed, 5 Jul 2017, Joseph Myers wrote: > I think the appropriate length depends on the size of the feature. > Typically we'd expect to list the new interfaces (which may sometimes be > quite a long list, e.g. the TS 18661-1 functions in 2.25), but in this > case a briefer description in terms of how they relate to existing > features for other types should suffice. Specifically, the following seems like a reasonable length for this feature to me. * On ia64, powerpc64le, x86-32, and x86-64, the math library now implements 128-bit floating point as defined by ISO/IEC/IEEE 60559:2011 (IEEE 754-2008) and ISO/IEC TS 18661-3:2015. Contributed by Paul E. Murphy, Gabriel F. T. Gomes, Tulio Magno Quites Machado Filho, and Joseph Myers. To compile programs that use this feature, the compiler must support 128-bit floating point with the type name _Float128 (as defined by TS 18661-3) or __float128 (the nonstandard name used by GCC for C++, and for C prior to version 7). _GNU_SOURCE or __STDC_WANT_IEC_60559_TYPES_EXT__ must be defined to make the new interfaces visible. The new functions and macros correspond to those present for other floating-point types (except for a few obsolescent interfaces not supported for the new type), with F128 or f128 suffixes; for example, strtof128, HUGE_VAL_F128 and cosf128. Following TS 18661-3, there are no printf or scanf formats for the new type; the strfromf128 and strtof128 interfaces should be used instead.
On Wed, Jul 5, 2017 at 12:55 PM, Joseph Myers <joseph@codesourcery.com> wrote: > > * On ia64, powerpc64le, x86-32, and x86-64, the math library now implements > 128-bit floating point as defined by ISO/IEC/IEEE 60559:2011 (IEEE > 754-2008) and ISO/IEC TS 18661-3:2015. Contributed by Paul E. Murphy, > Gabriel F. T. Gomes, Tulio Magno Quites Machado Filho, and Joseph Myers. > > To compile programs that use this feature, the compiler must support > 128-bit floating point with the type name _Float128 (as defined by TS > 18661-3) or __float128 (the nonstandard name used by GCC for C++, and for > C prior to version 7). _GNU_SOURCE or __STDC_WANT_IEC_60559_TYPES_EXT__ > must be defined to make the new interfaces visible. > > The new functions and macros correspond to those present for other > floating-point types (except for a few obsolescent interfaces not > supported for the new type), with F128 or f128 suffixes; for example, > strtof128, HUGE_VAL_F128 and cosf128. Following TS 18661-3, there are no > printf or scanf formats for the new type; the strfromf128 and strtof128 > interfaces should be used instead. This also looks reasonable to me.
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 <https://github.com/thkukuk/>. 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: