Add custom printf version (Draft)

[chqrlie]

Add custom printf version

• add js_snprintf, js_printf... to handle extra conversions:
  • support for wxx length modifier
  • support for %b and %B
  • %oa and %#oa to convert JSAtom values
  • %ps to convert JSString values
• add dbuf_vprintf_fun replaceable dbuf_printf handler
• change JS_DumpString to JS_FormatString to convert JSSAtom to quoted strings
• change JS_AtomGetStrRT to JS_FormatAtom to convert JSAtom to strings
• change JS_AtomGetStr to return direct string pointer for builtin atoms
• remove print_atom
• use custom conversions for trace messages and error messages
• add support for %b, %B and w length modifier in std.printf
• remove error handlers: JS_ThrowTypeErrorAtom and JS_ThrowSyntaxErrorAtom
• add is_lower_ascii() and to_lower_ascii()
• add floating point conversions and wide string conversions
• unbreak compilation: prevent name collision on pow10
• minimize vsnprintf calls in dbuf_vprintf_default

[bnoordhuis]

I'm sorta lukewarm on this. Prior experiences with homegrown (s)printf implementations have been a mixed bag.

I mean, I get the appeal but complex features need to pay for themselves and I'm not quite seeing that. Is there one killer feature in particular that made you start on this?

[chqrlie]

I'm sorta lukewarm on this. Prior experiences with homegrown (s)printf implementations have been a mixed bag.

I mean, I get the appeal but complex features need to pay for themselves and I'm not quite seeing that. Is there one killer feature in particular that made you start on this?

Hi @bnoordhuis

I understand your concerns, I have invested a hefty amount of work into this, both for pleasure (I like to hack printf for breakfast*) and for actual goals in this project:

• fix portability issues with some printf implementations that have non standard or implementation defined behavior, not to mention obsolete implementations that lack C99 support.
• fix the floating point to string conversions rounding issues. This occurs on Windows, but also in macOS: a current example is v8.sh failures on my laptop (addressed in Improve number to string conversions #400):

   === number-tostring-func.js
  +Failure (0.5.toFixed(0)): expected <"1"> found <"0">
  +Failure ((-0.5).toFixed(0)): expected <"-1"> found <"-0">
   === number-tostring-small.js
   === number-tostring.js
  +Failure (0.5.toFixed(0)): expected <"1"> found <"0">
  +Failure ((-0.5).toFixed(0)): expected <"-1"> found <"-0">
   === numops-fuzz-part1.js
  

• more generally improve the number to string conversion that currently calls snprintf multiple times with varying precision settings to implement the minimum representation and the round away from zero semantics that are not supported by snprintf portably and are difficult to emulate.
• to implement proper javascript rounding on RNDN architectures, we change the current rounding mode using fesetround(), which may not be thread-safe for pre-C23 targets.
• avoid locale issues or handle them explicitly: the library printf uses the current locale for floating point conversions, which may produce incorrect output if the decimal point differs from '.'. Changing the locale is not thread safe and passing the locale dynamically is not portable. If the host application uses locales for its own purposes, QuickJS would be affected beyond fixing (actually I hope I fixed this in Improve number to string conversions #400).
• radix conversions are also imperfect and produce subtly different output from node. My implementation of floating point conversions will help with that too.
• conversions from string to numbers (js_strtod) should also be rewritten to ensure proper rounding in a portable fashion to all targets and remove locale dependencies. This would also avoid the copying pass to remove the _ separators.
• extensions for JSAtoms, JSStrings and possibly other objects allow for much simpler code for traces and error message construction.

The implementation in the current PR still uses the library snprintf for floating point values, but I am testing a complete version and will post that shortly. I shall also add a complete test suite with 450000 tests: qjs_printf passes and is on average 50% faster than the C library versions on Apple and linux).

As you have noticed, Fabrice and I tried hard to avoid depending on other packages to keep the project self contained and reliable. printf is a remaining stone is our shoes that I would like to get rid of too.

---

_{(*) Implementing printf for breakfast is a good challenge for C experts, getting all the integer conversions right is feasible, but handling the floating point conversions correctly (and efficiently) does require time and effort :)}

[bnoordhuis]

@chqrlie I don't have much time this week and (maybe) next week (school holidays) but I'll try to review this at the first possible opportunity.

[chqrlie]

@chqrlie I don't have much time this week and (maybe) next week (school holidays) but I'll try to review this at the first possible opportunity.

Thank you. I have not plugged js_dtoa into this yet, so you may want to wait for a final version... I'll keep you posted.

[bnoordhuis]

Sorry, I dropped the ball on this one. It was around the time I fell ill last year.

It definitely needs a rebase now. There are conflicts all over the place.

[chqrlie]

Sorry, I dropped the ball on this one. It was around the time I fell ill last year.

It definitely needs a rebase now. There are conflicts all over the place.

Yes, I'll try and fix that this week.

[bnoordhuis]

I had a quick look-over and I think I'm not a huge fan of rolling so many changes into a single commit. Consider how it affects git-revert, git-bisect, etc. Also: drag to review - time to land tends to grow exponentially with change size.

Is there a way to do this in a more piecemeal fashion?

[chqrlie]

I had a quick look-over and I think I'm not a huge fan of rolling so many changes into a single commit. Consider how it affects git-revert, git-bisect, etc. Also: drag to review - time to land tends to grow exponentially with change size.

Yes, I agree, assessing some of these subtle patches is a headache and assessing the main chunk (printf replacement) is much worse so it is important to separate these patches into identifiable failure points in future git dissect attempts.

Is there a way to do this in a more piecemeal fashion?

Definitely. I am travelling right now but will try posting separate PRs for the preliminary work.