(1) Consistent, repeatable results across all platforms - the library will not fail or degrade because of a platforms dodgy printf() implementation.
(2) SQLite's printf includes extensions like %q and %Q that help prevent SQL injection attacks. These are used internally. (grep for '%q' and '%Q' in the SQLite sources and see for yourself.)
(3) Nothing like sqlite3_mprintf() is available from standard libraries. And yet it is a very useful and important interface.
(4) SQLite has a printf() SQL function for formatting text. I don't know of any way to build that using a standard-library printf() implementation - you need to have direct access to the printf() source code to make it work from SQL.
(5) Library printf() implementations are often subject to LOCALE, which means that if "3.14159" is render as "3,14159" (as it is for some LOCALEs) it will break SQL syntax rules when used to construct an SQL statement.
I can probably think of other reasons, but those are the ones that come quickly to mind.
Looks like SQLite is historically targetting a range of platforms that includes ones without a fully functional, standard-compliant printf(). Yes, that means it doesn't rely on much of anything elese provided by the C runtime and the operating system.
That reminds me: as an emebedded systems programmer, I've encountered a proper standards-compliant C compiler that allowed switching between a full, light and no version of printf() with a switch - you were allowed to omit just that one bit of the standard library for some significant savings in RAM and ROM usage. Of course, it was a little wonder for me at the time that a standards-compliant C compiler existed on that platform at all, but to realize that printf() function could often be the most heavy part of the application was another thing altogether... mind-expanding, really. The lesser C compiler vendors would just cut corners on the standard library implementation where they see fit, but that one left standard compliance as an option.
(2) SQLite's printf includes extensions like %q and %Q that help prevent SQL injection attacks. These are used internally. (grep for '%q' and '%Q' in the SQLite sources and see for yourself.)
(3) Nothing like sqlite3_mprintf() is available from standard libraries. And yet it is a very useful and important interface.
(4) SQLite has a printf() SQL function for formatting text. I don't know of any way to build that using a standard-library printf() implementation - you need to have direct access to the printf() source code to make it work from SQL.
(5) Library printf() implementations are often subject to LOCALE, which means that if "3.14159" is render as "3,14159" (as it is for some LOCALEs) it will break SQL syntax rules when used to construct an SQL statement.
I can probably think of other reasons, but those are the ones that come quickly to mind.