aboutsummaryrefslogtreecommitdiff
path: root/stdio-common/Makefile
diff options
context:
space:
mode:
authorJoseph Myers <joseph@codesourcery.com>2021-11-10 15:52:21 +0000
committerJoseph Myers <joseph@codesourcery.com>2021-11-10 15:52:21 +0000
commit309548bec3b89022bbc81a372ec3e9240211d799 (patch)
tree00606a6f381f0f9ed70358421305e4e229a79788 /stdio-common/Makefile
parent3387c40a8bbad5faf85b1feb56429cb20feaa640 (diff)
downloadglibc-309548bec3b89022bbc81a372ec3e9240211d799.zip
glibc-309548bec3b89022bbc81a372ec3e9240211d799.tar.gz
glibc-309548bec3b89022bbc81a372ec3e9240211d799.tar.bz2
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).
Diffstat (limited to 'stdio-common/Makefile')
-rw-r--r--stdio-common/Makefile3
1 files changed, 2 insertions, 1 deletions
diff --git a/stdio-common/Makefile b/stdio-common/Makefile
index 803f16d..bbb3a2c 100644
--- a/stdio-common/Makefile
+++ b/stdio-common/Makefile
@@ -70,7 +70,8 @@ tests := tstscanf test_rdwr test-popen tstgetln test-fseek \
tst-vfprintf-width-prec-alloc \
tst-printf-fp-free \
tst-printf-fp-leak \
- test-strerr
+ test-strerr \
+ tst-printf-binary
test-srcs = tst-unbputc tst-printf tst-printfsz-islongdouble