This adds formatted input/output of binary integer numbers to the printf(), scanf(), and strtol() families, including their wide-character counterparts.
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
With all the code repetitions, you'd think a macro might not be bad to have for all the places that need to do this parsing.
It's no worse than what we have today, but as the number of cases have grown, it's starting to be difficult to manage.
lib/libc/iconv/_strtol.h | ||
---|---|---|
96 | '0' || == '1'also would work, but I'm not sure it would generate better code and so might not be worth breaking the pattern with the other bases. |
Also, it might make sense to include a pointer to what N2630 is or a spec or something. Google doesn't give me good search results when I look for it without getting kinda specific. A simple URL for the commit message would do wonders.
Also, it might make sense to include a pointer to what N2630 is or a spec or something
Yeah, and reference it in the commit message subject too. N2630 doesn't mean much to me but something like "base 2 support for printf/scanf et al" would be useful
I'm not convinced using macros for these functions is going to be straightforward / make things more clear.
lib/libc/stdio/vfscanf.c | ||
---|---|---|
441 | should p == start on the next line for style(9)? |
Still thing that having a 'is_prefix_binary()' macro would make the code cleaner and avoid a lot of duplication (that admittedly we put up with for hex, there should be one for that too), but I lost that argument in the reviews...
Most of the added complexity arises from the fact that the binary prefix is also a valid hexadecimal number... in fact, any binary number, with or without prefix, is also a valid unprefixed hexadecimal number. And we need to handle all cases with at most one character of look-ahead since that's all we're guaranteed to be able to push back to the stream.