lib_libvsprintf.c: add Add support for %pB parameter.

[Otpvondoiats]

Summary

1. This is a new function that implements the method of printing the serialized data of the structure in a similar way to %pV %pS.
2. Add LIBC_PRINT_EXTENSION option to control the opening of %p*, which is closed by default

Impact

None. This is a new parameter parsing and does not affect existing parameters.

Testing

pc: ubuntu 20.04,x86, SIM

void orb_info(FAR const char *format, FAR const char *name,
              FAR const void *data)
{
  struct lib_stdoutstream_s stdoutstream;
  struct va_format vaf;

  vaf.fmt = format;
  vaf.va  = (va_list *)data;

  lib_stdoutstream(&stdoutstream, stdout);
  lib_sprintf(&stdoutstream.common, "%s(now:%" PRIu64 "):%pB\n",
              name, orb_absolute_time(), &vaf);
}

order: uorb_listener -n 10 sensor_accel_uncal out:

Mointor objects num:1
object_name:sensor_accel_uncal, object_instance:0
sensor_accel_uncal(now:57777592500):timestamp:57777591900,x:0.081402,y:0.689530,z:9.897630,temperature:31.253906
sensor_accel_uncal(now:57777632700):timestamp:57777632300,x:0.126893,y:0.792481,z:9.911995,temperature:31.253906
sensor_accel_uncal(now:57777672800):timestamp:57777672500,x:0.055066,y:0.708684,z:9.892841,temperature:31.253906
sensor_accel_uncal(now:57777713500):timestamp:57777713200,x:0.107739,y:0.682347,z:9.861717,temperature:31.253906
sensor_accel_uncal(now:57777754000):timestamp:57777753500,x:-0.040701,y:0.677559,z:9.751583,temperature:31.253906
sensor_accel_uncal(now:57777794200):timestamp:57777793800,x:0.117316,y:0.751779,z:9.797073,temperature:31.253906
sensor_accel_uncal(now:57777834600):timestamp:57777834100,x:0.081402,y:0.732626,z:9.734824,temperature:31.253906
sensor_accel_uncal(now:57777874700):timestamp:57777874400,x:0.062249,y:0.711078,z:9.732430,temperature:31.253906
sensor_accel_uncal(now:57777915000):timestamp:57777914700,x:0.114922,y:0.826000,z:9.742006,temperature:31.253906
sensor_accel_uncal(now:57777955600):timestamp:57777955000,x:0.098162,y:0.756568,z:9.809045,temperature:31.253906

timestamp:57777591900,x:0.081402,y:0.689530,z:9.897630,temperature:31.253906 is B parameter output results

[lupyuen]

[Experimental Bot, please feedback here]

No, this PR does not meet the NuttX requirements.

Missing Information:

• Summary:
  • Lacks a clear explanation of why this change is necessary. Is it a bug fix? A feature request? Provide context.
  • "uorb info call" is too specific. What is the broader functional area impacted (e.g., logging, debugging, data formatting)?
• Impact:
  • While you state "None," you need to address all impact points. Even if the answer is "NO," explicitly state it for clarity.
  • Your provided code snippet seems like it belongs in the "Testing" section.
• Testing:
  • Insufficient detail:
    • You need to list the specific host operating systems, CPUs, compilers, target architectures, and boards you used for testing.
    • Provide actual testing logs, not just placeholders.
  • Unclear what is being tested: The code snippet is not self-explanatory. Describe the test case and expected results both before and after your change.

Recommendations:

1. Expand the Summary: Explain the motivation for adding %pB. Is there a specific use case or issue it solves?
2. Complete the Impact Section: Even if the impact is minimal, go through each point and confirm its status.
3. Provide Detailed Testing Information:
   • List all relevant host and target configurations used.
   • Include complete testing logs demonstrating the issue before your change and the successful outcome after.
   • Clearly explain the purpose of your test code and the expected results.

By addressing these points, your PR will be more informative and likely to be reviewed and merged more quickly.

[yamt]

This is a new function that implements the method of printing the serialized data of the structure in a similar way to %pV %pS.

i was not aware of %pV and %pS. their way to extend the functionality seems quite broken as it prevents us from providing standard %p.

please don't follow the mistake.

[Otpvondoiats]

[xiaoxiang781216]

This is a new function that implements the method of printing the serialized data of the structure in a similar way to %pV %pS.

i was not aware of %pV and %pS. their way to extend the functionality seems quite broken as it prevents us from providing standard %p.

Linux kernel uses the similar approach to extend the format specifier: https://www.kernel.org/doc/Documentation/printk-formats.txt

please don't follow the mistake.

Could you give more info why it isn't good?

[yamt]

This is a new function that implements the method of printing the serialized data of the structure in a similar way to %pV %pS.

i was not aware of %pV and %pS. their way to extend the functionality seems quite broken as it prevents us from providing standard %p.

Linux kernel uses the similar approach to extend the format specifier: [https://www.kernel.org/doc/Documentation/printk-formats.txt](https://www.%5Bkernel.org/doc/Documentation/printk-formats.txt%5D(https://www.kernel.org/doc/Documentation/printk-formats.txt))

printk is a non-standard linux-internal api, which isn't meant to conform any standards.

please don't follow the mistake.

Could you give more info why it isn't good?

printf("%pS", NULL) should yield something like "0x0S".

besides that, these kinds of extensions are not recognized by the compiler's __format__ attribute.

[xiaoxiang781216]

This is a new function that implements the method of printing the serialized data of the structure in a similar way to %pV %pS.

i was not aware of %pV and %pS. their way to extend the functionality seems quite broken as it prevents us from providing standard %p.

Linux kernel uses the similar approach to extend the format specifier: [https://www.kernel.org/doc/Documentation/printk-formats.txt](https://www.%5Bkernel.org/doc/Documentation/printk-formats.txt%5D(https://www.kernel.org/doc/Documentation/printk-formats.txt))

printk is a non-standard linux-internal api, which isn't meant to conform any standards.

please don't follow the mistake.

Could you give more info why it isn't good?

printf("%pS", NULL) should yield something like "0x0S".

besides that, these kinds of extensions are not recognized by the compiler's __format__ attribute.

Ok, @Otpvondoiats let's add an option in Kconfig to control this special format specifier.

[Otpvondoiats]

This is a new function that implements the method of printing the serialized data of the structure in a similar way to %pV %pS.

i was not aware of %pV and %pS. their way to extend the functionality seems quite broken as it prevents us from providing standard %p.

Linux kernel uses the similar approach to extend the format specifier: [https://www.kernel.org/doc/Documentation/printk-formats.txt](https://www.%5Bkernel.org/doc/Documentation/printk-formats.txt%5D(https://www.kernel.org/doc/Documentation/printk-formats.txt))

printk is a non-standard linux-internal api, which isn't meant to conform any standards.

please don't follow the mistake.

Could you give more info why it isn't good?

printf("%pS", NULL) should yield something like "0x0S". besides that, these kinds of extensions are not recognized by the compiler's __format__ attribute.

Ok, @Otpvondoiats let's add an option in Kconfig to control this special format specifier.

Get

[xiaoxiang781216]

@yamt please review the new implementation which disable the extension by default.

[yamt]

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.

isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

[Otpvondoiats]

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.

isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

hi，This type of API is a special interface, and different systems implement it differently. If add a new API, also need to enable a similar kconfig to control the opening of the interface.

[xiaoxiang781216]

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system.

isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

It requires changing all kernel caller, which is a huge change. The current solution already reduces the possibility of confliction as small as possible.

[yamt]

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system. isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

hi，This type of API is a special interface, and different systems implement it differently. If add a new API, also need to enable a similar kconfig to control the opening of the interface.

the point is that it can be done w/o affecting users of the standard printf family.

[yamt]

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system. isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

It requires changing all kernel caller, which is a huge change. The current solution already reduces the possibility of confliction as small as possible.

no. you only need to use the new interface when you actually use %pB etc, which i suppose very rare.

[yamt]

an alternative approach is to use a non-conflicting modifier/specifier. it still has a possibility of feature conflicts and has __format__ attribute problems though.

[Otpvondoiats]

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system. isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

hi，This type of API is a special interface, and different systems implement it differently. If add a new API, also need to enable a similar kconfig to control the opening of the interface.

the point is that it can be done w/o affecting users of the standard printf family.

Yes, there is no problem with the new API, but the current patch is only to solve the uorblistener printing problem. The new interface plan can be added and updated later, and this work is a big project.

[Otpvondoiats]

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system. isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

It requires changing all kernel caller, which is a huge change. The current solution already reduces the possibility of confliction as small as possible.

no. you only need to use the new interface when you actually use %pB etc, which i suppose very rare.

@yamt hi, Can it be merged?

[xiaoxiang781216]

%pB follow the current/Linux design, and the new option minimize the potential conflict, can we move the optimization to the next phase?

[yamt]

%pB follow the current/Linux design, and the new option minimize the potential conflict, can we move the optimization to the next phase?

what linux design are you talking about? i explained that we were not following what printk does. my request is not about optimization but conformation to standards.

[yamt]

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system. isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

It requires changing all kernel caller, which is a huge change. The current solution already reduces the possibility of confliction as small as possible.

no. you only need to use the new interface when you actually use %pB etc, which i suppose very rare.

@yamt hi, Can it be merged?

i'm against it.

[Otpvondoiats]

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system. isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

It requires changing all kernel caller, which is a huge change. The current solution already reduces the possibility of confliction as small as possible.

no. you only need to use the new interface when you actually use %pB etc, which i suppose very rare.

@yamt hi, Can it be merged?

i'm 对 it.

Thanks for review

[yamt]

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system. isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

hi，This type of API is a special interface, and different systems implement it differently. If add a new API, also need to enable a similar kconfig to control the opening of the interface.

the point is that it can be done w/o affecting users of the standard printf family.

Yes, there is no problem with the new API, but the current patch is only to solve the uorblistener printing problem. The new interface plan can be added and updated later, and this work is a big project.

do you need it just for printf? or all printf families?

[yamt]

also, have you considered a less intrusive approach? https://github.com/apache/nuttx/pull/13536#issuecomment-2370184919

[Otpvondoiats]

Refere

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system. isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

hi，This type of API is a special interface, and different systems implement it differently. If add a new API, also need to enable a similar kconfig to control the opening of the interface.

the point is that it can be done w/o affecting users of the standard printf family.

Yes, there is no problem with the new API, but the current patch is only to solve the uorblistener printing problem. The new interface plan can be added and updated later, and this work is a big project.

do you need it just for printf? or all printf families?

%pB is used to print the structure of the uorb

[Otpvondoiats]

also, have you considered a less intrusive approach? #13536 (comment)

The current change is a minimal change to the system, and if need to extract %p* related stuff separately and encapsulate it into a new interface, this task plan is future, not handled in this patch. After all, this type existed inside the system before.

[yamt]

Refere

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system. isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

hi，This type of API is a special interface, and different systems implement it differently. If add a new API, also need to enable a similar kconfig to control the opening of the interface.

the point is that it can be done w/o affecting users of the standard printf family.

Yes, there is no problem with the new API, but the current patch is only to solve the uorblistener printing problem. The new interface plan can be added and updated later, and this work is a big project.

do you need it just for printf? or all printf families?

%pB is used to print the structure of the uorb

do you mean, only printf, not snprintf etc?

[yamt]

also, have you considered a less intrusive approach? #13536 (comment)

The current change is a minimal change to the system, and if need to extract %p* related stuff separately and encapsulate it into a new interface, this task plan is future, not handled in this patch. After all, this type existed inside the system before.

i'm not requesting to fix other problematic extensions in this PR. however, %pB is a problem of this PR.

[Otpvondoiats]

Refere

@yamt please review the new implementation which disable the extension by default.

i feel it's difficult to use a kconfig which alters the behavior of very basic things like printf. when you want to enable it, you need to audit every uses of printf family functions in your system. isn't it simper to provide an alternative api, say, nuttx_printf, to provide the extension? (similarly to linux printk)

hi，This type of API is a special interface, and different systems implement it differently. If add a new API, also need to enable a similar kconfig to control the opening of the interface.

the point is that it can be done w/o affecting users of the standard printf family.

Yes, there is no problem with the new API, but the current patch is only to solve the uorblistener printing problem. The new interface plan can be added and updated later, and this work is a big project.

do you need it just for printf? or all printf families?

%pB is used to print the structure of the uorb

do you mean, only printf, not snprintf etc?

%pB is in the vsprintf_internal function, all printfs are affected, but currently only uorb is using this function.

[Otpvondoiats]

also, have you considered a less intrusive approach? #13536 (comment)

The current change is a minimal change to the system, and if need to extract %p* related stuff separately and encapsulate it into a new interface, this task plan is future, not handled in this patch. After all, this type existed inside the system before.

i'm not requesting to fix other problematic extensions in this PR. however, %pB is a problem of this PR.

Under Linux, there is no interface to print the structure buffer with Printf. If this function is drawn from Printf alone, the amount of changes will be very large. Or do you have a good way? Thanks ~

[yamt]

also, have you considered a less intrusive approach? #13536 (comment)

The current change is a minimal change to the system, and if need to extract %p* related stuff separately and encapsulate it into a new interface, this task plan is future, not handled in this patch. After all, this type existed inside the system before.

i'm not requesting to fix other problematic extensions in this PR. however, %pB is a problem of this PR.

Under Linux, there is no interface to print the structure buffer with Printf.

how is the situation in linux related to this PR?

If this function is drawn from Printf alone, the amount of changes will be very large. Or do you have a good way? Thanks ~

i'm not sure if i understand this sentence: "If this function is drawn from Printf alone, the amount of changes will be very large."

which function is "this function"? what do you mean by "drawn from printf alone"?

even if you implement the functionality in your app using lib_bsprintf and printf as of today, it won't be "very large".

also, i have already suggested at least two alternative approaches.

[yamt]

i guess the least invasive approach would be something similar to strftime. ie. have a separate function to create a string representation. (and use printf %s to print it.)