glibc

Tree: 42e48e720c

Author	SHA1	Message	Date
Paul Eggert	dff8da6b3e	Update copyright dates with scripts/update-copyrights	2 years ago
Joseph Myers	2d4728e606	Update printf %b/%B C2x support WG14 recently accepted two additions to the printf/scanf %b/%B support: there are now PRIb* and SCNb* macros in <inttypes.h>, and printf %B is now an optional feature defined in normative text, instead of recommended practice, with corresponding PRIB* macros that can also be used to test whether that optional feature is supported. See N3072 items 14 and 15 for details (those changes were accepted, some other changes in that paper weren't). Add the corresponding PRI* macros to glibc and update one place in the manual referring to %B as recommended. (SCNb* should naturally be added at the same time as the corresponding scanf %b support.) Tested for x86_64 and x86.	3 years ago
Joseph Myers	6d7e8eda9b	Update copyright dates with scripts/update-copyrights	3 years ago
Paul Eggert	581c785bf3	Update copyright dates with scripts/update-copyrights I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 7061 files FOO. I then removed trailing white space from math/tgmath.h, support/tst-support-open-dev-null-range.c, and sysdeps/x86_64/multiarch/strlen-vec.S, to work around the following obscure pre-commit check failure diagnostics from Savannah. I don't know why I run into these diagnostics whereas others evidently do not. remote: * 912-#endif remote: * 913: remote: * 914- remote: * error: lines with trailing whitespace found ... remote: *** error: sysdeps/unix/sysv/linux/statx_cp.c: trailing lines	4 years ago
Joseph Myers	309548bec3	Support C2X printf %b, %B C2X adds a printf %b format (see <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2630.pdf>, accepted for C2X), for outputting integers in binary. It also has recommended practice for a corresponding %B format (like %b, but %#B starts the output with 0B instead of 0b). Add support for these formats to glibc. One existing test uses %b as an example of an unknown format, to test how glibc printf handles unknown formats; change that to %v. Use of %b and %B as user-registered format specifiers continues to work (and we already have a test that covers that, tst-printfsz.c). Note that C2X also has scanf %b support, plus support for binary constants starting 0b in strtol (base 0 and 2) and scanf %i (strtol base 0 and scanf %i coming from a previous paper that added binary integer literals). I intend to implement those features in a separate patch or patches; as discussed in the thread starting at <https://sourceware.org/pipermail/libc-alpha/2020-December/120414.html>, they will be more complicated because they involve adding extra public symbols to ensure compatibility with existing code that might not expect 0b constants to be handled by strtol base 0 and 2 and scanf %i, whereas simply adding a new format specifier poses no such compatibility concerns. Note that the actual conversion from integer to string uses existing code in _itoa.c. That code has special cases for bases 8, 10 and 16, probably so that the compiler can optimize division by an integer constant in the code for those bases. If desired such special cases could easily be added for base 2 as well, but that would be an optimization, not actually needed for these printf formats to work. Tested for x86_64 and x86. Also tested with build-many-glibcs.py for aarch64-linux-gnu with GCC mainline to make sure that the test does indeed build with GCC 12 (where format checking warnings are enabled for most of the test).	5 years ago

5 Commits (42e48e720c78ab75eb8def9e866da52b0ac278df)