Be wary about using an AI that rejects a simple PR (change "return str;" into "return ptr;") based on false statements ("Your PR contains a critical error — the complete removal of return statements from the u_utoa function."). Details on https://github.com/Ferki-git-creator/Uprintf/pull/3#issuecom...
I encourage you to continue working on your projects.
Okay, I'll review the answer, and to tell you the truth, I'm improving the code and comments with the help of AI.
Well, of course, I did the ideas and other things myself, and I understand that you may not like this. AI is a controversial topic now, but I still have to thank you. I have the feeling that you are more worried about my project than I am.
Maybe the rabbit hole is much deeper than it seems.
Is it really possible to reconcile "no bloat" with "fully standard compliant"?
Maybe have a look at https://github.com/eyalroz/printf, if only for the test suite, which looks pretty comprehensive and still fails.
Maybe "key features" does not mean the same in all projects, making every project appear "unnecessarily bloated while missing key features" in every other context?
Nice. Comprehensive unit tests are indeed welcome.
Even a simple test code that tests all features, flags combinations, etc, and outputs a log.
It will make easy for anyone to run it and compare the logs.
I had a bug:
u_printf( my_output_cb, NULL, "%d" NL, -42 );
prints:
--42
I may have found an explanation.
In u_parse_format(),
case 'i':
calls
u_itoa( value, buffer, 10, false );
which outputs minus sign.
Then
if ( number )
does
if ( sign )
{
output_cb( '-', ctx );
chars_written++;
}
which outputs another minus sign.
Nice work. I always have understood that snprintf does not write a null character when the produced string is longer than the given size. The snprintf function also can be called with a null pointer to calculate the length of the produced string.
> I always have understood that snprintf does not write a null character when the produced string is longer than the given size.
snprintf always null-terminates when the buffer length is greater than 0 and there's no error. That is, if snprintf returns >= 0 and the buffer length is > 0, the output is null-terminated.
It was first added to the Single UNIX Specification (SUS) in 1997. Perhaps there was some oddball non-conformant implementation at the time, but in those cases the standard would usually use a different name.
There's the infamous strncpy, of course, which understandably could cause some confusion. And various non-vendor faux-snprintf implementations, like uprintf, that have different semantics. It's hazardous to reuse a standardized name like snprintf, even as a suffix, in an API but not implement the same fundamental semantics.
Thanks, I will make and add unit tests As you requested, I'm already starting to do it, but in the meantime, if you want, you can support the project with a star. :)
Be wary about using an AI that rejects a simple PR (change "return str;" into "return ptr;") based on false statements ("Your PR contains a critical error — the complete removal of return statements from the u_utoa function."). Details on https://github.com/Ferki-git-creator/Uprintf/pull/3#issuecom...
I encourage you to continue working on your projects.
https://onlinedocs.microchip.com/oxy/GUID-317042D4-BCCE-4065...
https://www.nongnu.org/avr-libc/user-manual/group__avr__stdl...
https://manpages.debian.org/testing/avr-libc/ultoa.3avr.en.h...
https://www.ibm.com/docs/en/zos/2.4.0?topic=functions-utoa-c...
https://www.qnx.com/developers/docs/6.3.2/neutrino/lib_ref/u...
Here is the documentation for the problem you mentioned.
Okay, I'll review the answer, and to tell you the truth, I'm improving the code and comments with the help of AI. Well, of course, I did the ideas and other things myself, and I understand that you may not like this. AI is a controversial topic now, but I still have to thank you. I have the feeling that you are more worried about my project than I am.
https://github.com/Ferki-git-creator/Uprintf/pull/3#issuecom...
Maybe the rabbit hole is much deeper than it seems.
Is it really possible to reconcile "no bloat" with "fully standard compliant"?
Maybe have a look at https://github.com/eyalroz/printf, if only for the test suite, which looks pretty comprehensive and still fails.
Maybe "key features" does not mean the same in all projects, making every project appear "unnecessarily bloated while missing key features" in every other context?
Nice. Comprehensive unit tests are indeed welcome. Even a simple test code that tests all features, flags combinations, etc, and outputs a log. It will make easy for anyone to run it and compare the logs.
I had a bug:
prints:--42
I may have found an explanation. In u_parse_format(), case 'i': calls u_itoa( value, buffer, 10, false ); which outputs minus sign.
Then if ( number ) does if ( sign ) { output_cb( '-', ctx ); chars_written++; } which outputs another minus sign.
Thanks, I will review your PR, and I have to thank you very much for saving my time and correcting the error.
Also floats seem to "forget" the integer part, and also have two minus signs when negative.
Created
https://github.com/Ferki-git-creator/Uprintf/issues/1
https://github.com/Ferki-git-creator/Uprintf/issues/2
https://github.com/Ferki-git-creator/Uprintf/pull/3
https://github.com/Ferki-git-creator/Uprintf/pull/4
Nice work. I always have understood that snprintf does not write a null character when the produced string is longer than the given size. The snprintf function also can be called with a null pointer to calculate the length of the produced string.
You could add a c file with some unittests.
> I always have understood that snprintf does not write a null character when the produced string is longer than the given size.
snprintf always null-terminates when the buffer length is greater than 0 and there's no error. That is, if snprintf returns >= 0 and the buffer length is > 0, the output is null-terminated.
This should be clear from your local snprintf(3) man page (e.g. https://man.openbsd.org/snprintf), but also see the C23 standard (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf) and POSIX (https://pubs.opengroup.org/onlinepubs/9799919799/).
You are right. I verified this myself. I do not know where I got this wrong. Maybe this was different in earlier implementations.
It was first added to the Single UNIX Specification (SUS) in 1997. Perhaps there was some oddball non-conformant implementation at the time, but in those cases the standard would usually use a different name.
There's the infamous strncpy, of course, which understandably could cause some confusion. And various non-vendor faux-snprintf implementations, like uprintf, that have different semantics. It's hazardous to reuse a standardized name like snprintf, even as a suffix, in an API but not implement the same fundamental semantics.
Thanks, I will make and add unit tests As you requested, I'm already starting to do it, but in the meantime, if you want, you can support the project with a star. :)
Would be nice to know the code size e.g. on arm-none-eabi!
Ok, I will make your request.