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

Otpvondoiats · 2024-09-19T04:20:36Z

Summary

This is a new function that implements the method of printing the serialized data of the structure in a similar way to %pV %pS.
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 · 2024-09-19T04:21:48Z

[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:

Expand the Summary: Explain the motivation for adding %pB. Is there a specific use case or issue it solves?
Complete the Impact Section: Even if the impact is minimal, go through each point and confirm its status.
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 · 2024-09-19T09:49:01Z

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 · 2024-09-20T02:58:58Z

xiaoxiang781216 · 2024-09-20T03:07:02Z

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.kernel.org/doc/Documentation/printk-formats.txt)

please don't follow the mistake.

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

yamt · 2024-09-20T04:30:56Z

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 · 2024-09-20T05:40:18Z

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 · 2024-09-20T06:14:19Z

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 · 2024-09-20T14:23:11Z

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

yamt · 2024-09-21T11:59:15Z

@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 · 2024-09-23T02:49:37Z

@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 · 2024-09-23T06:41:05Z

@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 · 2024-09-24T05:06:18Z

@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 · 2024-09-24T05:07:18Z

@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 · 2024-09-24T05:12:20Z

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 · 2024-09-24T10:23:16Z

@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 · 2024-09-26T02:59:24Z

@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 · 2024-09-26T03:04:12Z

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

yamt · 2024-09-26T07:45:50Z

%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 · 2024-10-04T04:34:55Z

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.)

Otpvondoiats · 2024-10-06T05:27:06Z

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.

The strftime method is not suitable for this purpose. It is necessary to apply for space according to the output buffer. In addition, the orb info function is a public function. It will take up a lot of CPU resources to apply for buffers of different lengths. In addition, the printf function itself takes up a lot of CPU resources. Again, buffer printing has been integrated into the sprintf function.

Otpvondoiats · 2024-10-06T05:44:24Z

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.

Our current disagreement is that the %p* type printing cannot be aligned with Linux, and the characters use %pB. Our current disagreement is that the %p* type printing cannot be aligned with Linux, and %pB* (%pBb) can be used as a subset extension.

yamt · 2024-10-07T02:33:34Z

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.

The strftime method is not suitable for this purpose. It is necessary to apply for space according to the output buffer. In addition, the orb info function is a public function. It will take up a lot of CPU resources to apply for buffers of different lengths. In addition, the printf function itself takes up a lot of CPU resources. Again, buffer printing has been integrated into the sprintf function.

i wonder why you read my comments very selectively.
how about "implement the functionality in your app using lib_bsprintf and printf as of today,"?

yamt · 2024-10-07T02:36:07Z

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.

Our current disagreement is that the %p* type printing cannot be aligned with Linux, and the characters use %pB. Our current disagreement is that the %p* type printing cannot be aligned with Linux, and %pB* (%pBb) can be used as a subset extension.

i don't know what your png files are about.
i guess they are documentation of linux printk.
printk is not printf.

Otpvondoiats · 2024-10-08T02:40:42Z

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.

Our current disagreement is that the %p* type printing cannot be aligned with Linux, and the characters use %pB. Our current disagreement is that the %p* type printing cannot be aligned with Linux, and %pB* (%pBb) can be used as a subset extension.

i don't know what your png files are about. i guess they are documentation of linux printk. printk is not printf.

I don't selectively read your comments。

I first disable these extension functions in the printf related functions inside Nuttx to ensure that they are not called in the standard printf, and then consider implementing a new API for this type of extension interface (printk)

yamt · 2024-10-09T04:05:09Z

I don't selectively read your comments。

ok.
then probably i just don't understand your logic.

I first disable these extension functions in the printf related functions inside Nuttx to ensure that they are not called in the standard printf,

do you mean CONFIG_LIBC_PRINT_EXTENSION?
i don't object against the option if it's meant as a process of deprecation/removal.
i don't think it's a good idea to add a new extension (%pB), though.

Otpvondoiats · 2024-10-11T12:09:48Z

I don't selectively read your comments。

ok. then probably i just don't understand your logic.

I first disable these extension functions in the printf related functions inside Nuttx to ensure that they are not called in the standard printf,

do you mean CONFIG_LIBC_PRINT_EXTENSION? i don't object against the option if it's meant as a process of deprecation/removal. i don't think it's a good idea to add a new extension (%pB), though.

My previous logic was:
First, this patch is to deal with the problem of size overflow, and use macros to prevent the size from overflowing.
Later, it became a discussion about %p.
The initial idea was that %p* related uses already existed, %pB might not conform to the definition of printk, and there was no such definition in printf.

GUIDINGLI · 2024-10-15T03:09:32Z

@yamt
Currently we support %pS %pV, why not allow add a %pB.
If you think that we should NOT support %pB, then you should remove %pS & %pV.
If you don't remove, then you have NO reason to prevent this PR.

Signed-off-by: likun17 <likun17@xiaomi.com>

…at specifier. Signed-off-by: likun17 <likun17@xiaomi.com>

yamt · 2024-10-16T03:00:08Z

@yamt Currently we support %pS %pV, why not allow add a %pB.

because it breaks more cases.

If you think that we should NOT support %pB, then you should remove %pS & %pV.

i agree they should be removed.

If you don't remove, then you have NO reason to prevent this PR.

i disagree. it breaks more cases.
printf("%pB", p) was not broken with %pS or %pV.

xiaoxiang781216 · 2024-10-16T09:50:32Z

At least, if you don't enable ALLSYMS or DEBUG_UORB, nothing breaks. Since both ALLSYMS and DEBUG_UORB is only for debugging, it's acceptable to lose some very vary compatibility in this case. Actually, we ship more 40 million devices which come from BLE only module, WiFi/BLE combo module, watch/band, TWS earbud, smarter speaker..., but I have not hear the incompatible report like this.

yamt · 2024-10-16T09:59:25Z

At least, if you don't enable ALLSYMS or DEBUG_UORB, nothing breaks. Since both ALLSYMS and DEBUG_UORB is only for debugging, it's acceptable to lose some very vary compatibility in this case. Actually, we ship more 40 million devices which come from BLE only module, WiFi/BLE combo module, watch/band, TWS earbud, smarter speaker..., but I have not hear the incompatible report like this.

i disagree. this should be reverted.

xiaoxiang781216 · 2024-10-16T10:09:37Z

why? if you revert, please ensure ALLSYMS or DEBUG_UORB still work as before.

yamt · 2024-10-16T10:11:59Z

why?

because it breaks printf.

if you revert, please ensure ALLSYMS or DEBUG_UORB still work as before.

why? they are misfeatures which should be removed too.

xiaoxiang781216 · 2024-10-16T10:17:14Z

why?

because it breaks printf.

LIBC_PRINT_EXTENSION, ALLSYMS and DEBUG_UORB aren't enable by default, how do they break printf?

if you revert, please ensure ALLSYMS or DEBUG_UORB still work as before.

why? they are misfeatures which should be removed too.

So, you want removing ALLSYMS functionality from the code base? @anchao please take a look.

yamt · 2024-10-16T10:21:46Z

why?

because it breaks printf.

LIBC_PRINT_EXTENSION, ALLSYMS and DEBUG_UORB aren't enable by default, how do they break printf?

if you never enable it, nothing breaks.
however, these options are meant to be enabled in some cases, right?
as i said earlier in this pr, it's unrealistic to audit all printf family usage when enabling the options.

if you revert, please ensure ALLSYMS or DEBUG_UORB still work as before.

why? they are misfeatures which should be removed too.

So, you want removing ALLSYMS functionality from the code base? @anchao please take a look.

at least they should be implemented in a way which doesn't break printf.

xiaoxiang781216 · 2024-10-16T10:34:06Z

Before the perfect way implement, is it more suitable to add the warning message in ALLSYMS and DEBUG_UORB Kconfig instead removing the related code？

See the discussion in apache#13536

yamt · 2024-10-17T07:00:00Z

Before the perfect way implement, is it more suitable to add the warning message in ALLSYMS and DEBUG_UORB Kconfig instead removing the related code？

do you mean something like #14378 ?

See the discussion in #13536

raiden00pl · 2024-10-19T11:12:00Z

@xiaoxiang781216 @Otpvondoiats after this PR nrf52832-dk/timer example crash in timer example. it revert 9de0465a8a fixes crash.
So it's possible that other things are broken too.

Otpvondoiats · 2024-10-19T15:13:08Z

at other things are bro

@xiaoxiang781216 @Otpvondoiats after this PR nrf52832-dk/timer example crash in timer example. it revert 9de0465a8a fixes crash. So it's possible that other things are broken too.

hi, What model is the NRF52832-DK development board you are using?

raiden00pl · 2024-10-19T16:14:52Z

@Otpvondoiats I see that the problem is different. This PR is not guilty, but after reverting the mentioned commit, the chip resets without a visible assert, making it harder to notice the error.

The culprit is here #13606 :)

Otpvondoiats · 2024-10-19T16:23:47Z

@Otpvondoiats I see that the problem is different. This PR is not guilty, but after reverting the mentioned commit, the chip resets without a visible assert, making it harder to notice the error.
The culprit is here #13606 :)

I looked at the code of NRF52832-DK, and there is no place to call %p related content. I will run a piece of this board to see if there is any error。

raiden00pl · 2024-10-19T16:31:10Z

You don't have to check, this PR is not guilty. With this PR for some reason crash is visible, but the reason is different. #13606 is the problem. False alarm on my side, sorry for the confusion :)

Otpvondoiats force-pushed the lk_printB branch from 158e341 to 4801852 Compare September 19, 2024 14:52

github-actions bot added the Size: XS The size of the change in this PR is very small label Sep 19, 2024

Otpvondoiats force-pushed the lk_printB branch from 4801852 to db50b89 Compare September 19, 2024 15:07

github-actions bot added Area: OS Components OS Components issues Size: S The size of the change in this PR is small and removed Size: XS The size of the change in this PR is very small labels Sep 20, 2024

xiaoxiang781216 requested a review from yamt September 20, 2024 14:22

Otpvondoiats force-pushed the lk_printB branch from ac9d5ec to c463c58 Compare September 20, 2024 14:57

xiaoxiang781216 requested a review from acassis September 20, 2024 19:00

Otpvondoiats mentioned this pull request Sep 23, 2024

Adapt %p* newly added LIBC_PRINT_EXTENSION kconfig configuration apache/nuttx-apps#2601

Merged

xiaoxiang781216 approved these changes Sep 24, 2024

View reviewed changes

Otpvondoiats force-pushed the lk_printB branch from c463c58 to 5eeaee8 Compare September 25, 2024 08:50

Otpvondoiats added 2 commits October 15, 2024 11:12

lib_libvsprintf.c: Add support for %pB parameter.

aac123f

Signed-off-by: likun17 <likun17@xiaomi.com>

lib_libvsprintf.c:add option in Kconfig to control "%p*" special form…

6161059

…at specifier. Signed-off-by: likun17 <likun17@xiaomi.com>

Otpvondoiats force-pushed the lk_printB branch from 5eeaee8 to 6161059 Compare October 15, 2024 03:12

GUIDINGLI merged commit 9de0465 into apache:master Oct 15, 2024
39 checks passed

yamt added a commit to yamt/incubator-nuttx that referenced this pull request Oct 17, 2024

Discourage the use of LIBC_PRINT_EXTENSION

c1ac275

See the discussion in apache#13536

yamt mentioned this pull request Oct 17, 2024

Discourage the use of LIBC_PRINT_EXTENSION #14378

Merged

xiaoxiang781216 pushed a commit that referenced this pull request Oct 17, 2024

Discourage the use of LIBC_PRINT_EXTENSION

4bfde88

See the discussion in #13536

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

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

Conversation

Otpvondoiats commented Sep 19, 2024 • edited Loading

Summary

Impact

Testing

lupyuen commented Sep 19, 2024

yamt commented Sep 19, 2024

Otpvondoiats commented Sep 20, 2024

xiaoxiang781216 commented Sep 20, 2024

yamt commented Sep 20, 2024

xiaoxiang781216 commented Sep 20, 2024

Otpvondoiats commented Sep 20, 2024

xiaoxiang781216 commented Sep 20, 2024

yamt commented Sep 21, 2024

Otpvondoiats commented Sep 23, 2024 • edited Loading

xiaoxiang781216 commented Sep 23, 2024

yamt commented Sep 24, 2024

yamt commented Sep 24, 2024

yamt commented Sep 24, 2024

Otpvondoiats commented Sep 24, 2024

Otpvondoiats commented Sep 26, 2024

xiaoxiang781216 commented Sep 26, 2024

yamt commented Sep 26, 2024

yamt commented Oct 4, 2024

Otpvondoiats commented Oct 6, 2024

Otpvondoiats commented Oct 6, 2024

yamt commented Oct 7, 2024

yamt commented Oct 7, 2024

Otpvondoiats commented Oct 8, 2024

yamt commented Oct 9, 2024

Otpvondoiats commented Oct 11, 2024

GUIDINGLI commented Oct 15, 2024

yamt commented Oct 16, 2024

xiaoxiang781216 commented Oct 16, 2024 • edited Loading

yamt commented Oct 16, 2024

xiaoxiang781216 commented Oct 16, 2024

yamt commented Oct 16, 2024

xiaoxiang781216 commented Oct 16, 2024

yamt commented Oct 16, 2024

xiaoxiang781216 commented Oct 16, 2024 • edited Loading

yamt commented Oct 17, 2024

raiden00pl commented Oct 19, 2024

Otpvondoiats commented Oct 19, 2024 • edited Loading

raiden00pl commented Oct 19, 2024 • edited Loading

Otpvondoiats commented Oct 19, 2024

raiden00pl commented Oct 19, 2024

Otpvondoiats commented Sep 19, 2024 •

edited

Loading

Otpvondoiats commented Sep 23, 2024 •

edited

Loading

xiaoxiang781216 commented Oct 16, 2024 •

edited

Loading

xiaoxiang781216 commented Oct 16, 2024 •

edited

Loading

Otpvondoiats commented Oct 19, 2024 •

edited

Loading

raiden00pl commented Oct 19, 2024 •

edited

Loading