> Given that this is an Apple operating system, we might know it has a snprintf_l function which takes an explicit locale, and hope that this would make it scale. Just pass NULL which means “use C locale”:
Right. My point is that the change from sprintf() to sprintf(..., NULL, ...) is a semantic-modifying change. For the purpose of understanding what's going on, that's fine. For the purpose of optimizing software, that's scary. And even scarier is that it seems somewhat more likely that the version under test is more correct than the version as shipped.
> Technically, there are no bugs anywhere above - all the functions work correctly
They were all correct. But yeah, scary how primitives can result in such poor performance. FWIW, they ended up using {fmt}: https://developer.blender.org/D13998
The point parent poster os making, is that previously, unless set_locale was being called by blender, the resulting export of a blender object was locale dependent. The change from sprintf(..) to sprintf(..., NULL), would then actually change the behavior (not just performance) of the program.
> Given that this is an Apple operating system, we might know it has a snprintf_l function which takes an explicit locale, and hope that this would make it scale. Just pass NULL which means “use C locale”:
And then the chart and discussion following it?