%#b with field width exceeds specified width

[nocodo189753]

Hi:
my test code is :

dbg("%#10b\n", 0xf);
dbg("%#10b\n", 0xff);
dbg("%#10b\n", 0x00);
dbg("%#010b\n", 0xff);
dbg("%#010b\n", 0x00);

output ('_' means space):

_____0b1111
0b11111111
____________0
0b011111111
0000000000

It seems:

1. if val is 0, then no "0b" prefix
2. "%#010b\n" have an extra 0, while width should be 10 ('0b' + 8bit) if I'm right

Is these a bug or I'm using it wrong?

My env:
keil mdk 5.36.0，with segger rtt output

#define dbg_log(...) fctprintf(putchar_custom_, (void *)0, __VA_ARGS__)
#define dbg_ext(...) fctprintf(putchar_custom_, (void *)1, __VA_ARGS__)
#define dbg dbg_log

void putchar_(char ch) { SEGGER_RTT_PutChar(0, ch); }
void putchar_custom_(char ch, void *arg) { SEGGER_RTT_PutChar((int)arg, ch); }

[eyalroz]

First, thank you for filing the issue.

Second - I'm assuming this issue manifests on regular desktop machines, since I have no idea what "segger rtt" is.

Now...

%b is a non-standard specifier. I am assuming we should treat it similarly to the %x specifier, but with base 2 instead of 16 .

So,

if val is 0, then no "0b" prefix

This is how x behaves - assuming no precision is set; and that's the case also in the alternative representation #x (and thus #b.

(to be continued)

[eyalroz]

I don't see the extra 0 you mentioned. Here are all of your testcases, with their %x equivalent printed by my printf_() and glibc's printf:

printf_("%x", 0xf)      : f
printf ("%x", 0xf)      : f
printf_("%b", 0xf)      : 1111
----
printf_("%#x", 0xf)     : 0xf
printf ("%#x", 0xf)     : 0xf
printf_("%#b", 0xf)     : 0b1111
----
printf_("%#10x", 0xf)   :        0xf
printf ("%#10x", 0xf)   :        0xf
printf_("%#10b", 0xf)   :     0b1111
----
printf_("%#10x", 0xff)  :       0xff
printf ("%#10x", 0xff)  :       0xff
printf_("%#10b", 0xff)  : 0b11111111
----
printf_("%#10x", 0x0)   :          0
printf ("%#10x", 0x0)   :          0
printf_("%#10b", 0x0)   :          0
----
printf_("%#010x", 0xff) :       0xff
printf ("%#010x", 0xff) :       0xff
printf_("%#010b", 0xff) : 0b11111111
----
printf_("%#010x", 0x0)  : 0000000000
printf ("%#010x", 0x0)  : 0000000000
printf_("%#010b", 0x0)  : 0000000000

(the single space after the : is part of the prefix and not due to the specifier replacement.)

[nocodo189753]

Thanks for your response.

1. I checked the c99 standard for alternative form, it did mentioned that

For x(or X) conversion, a nonzero result has 0x(or 0X) prefixed to it.

end of question.

2. The %#010b did output 0b011111111 in my test.

In print_integer_finalization :

// handle hash
  if (flags & (FLAGS_HASH | FLAGS_POINTER)) {
    if (!(flags & FLAGS_PRECISION) && len && ((len == precision) || (len == width))) {
      // Let's take back some padding digits to fit in what will eventually
      // be the format-specific prefix
      if (unpadded_len < len) {
        len--;
      }
      if (len && (base == BASE_HEX)) {
        if (unpadded_len < len) {
          len--;
        }
      }
    }
   ...
}

before those code:
flags = FLAGS_HASH | FLAGS_ZEROPAD
base = BASE_BINARY
buf = '1111111100'
len = 10
unpadded_len=8

since (len && (base == BASE_HEX)) is false, this makes only 1 byte 'take backed'，after prefix append buf becomes 111111110b0, an extra 0 appeared.

[eyalroz]

I can now reproduce the issue. Not sure why I wasn't seeing it before. Expect a fix soon...

[eyalroz]

@nocodo189753 : Please try the head of the develop branch and make sure the bug is resolved for you as well.