Hi friends!

BACKGROUND

Since birth, libcurl has provided the printf family of functions in its
API. Meanwhile, they have been mentioned as deprecated and we've discouraged
users from using them since 2004.

They're also not documented much, so users don't actually know exactly what
they support and hence we don't really promise anything solid.

WHY

We have our own set of *printf clones to make sure we have the same set of
functions on all platforms, since when we started this in particular
snprintf() wasn't universal and there were disagreements on what the functions
should return etc, and even how to output things like size_t variables etc.

We don't use the native *printf() versions on any platform to make sure we
have the exact same functionality everywhere and making sure the native one
works exactly as our own is tricky and error-prone. Plus it would reduce the
testing we get.

... and then as we already made them for our own sake, we made them externally
accessible as well.

PROBLEM

They're pretty slow. The glibc alternatives on my machine are more than twice
as fast for the test strings I've thrown at them.

IDEA

Make them faster! A challenge here is to do that while still working on all
platforms and targets.

1.

One first shortcut I'd like to make is to remove support for the '[num]$'
operator. It is used to tell *printf() which argument to pick for the
following flag. Like "%2$d" picks the second argument to use for the integer
output instead of just using the next in the argument list.

This feature is not used - and has never been used - by curl. It is not
documented to work. It is not even tested to verify that it works. Removing
support for this feature allows the code to be simplified somewhat.

2.

The next removal I want to do is to drop support for %I, %I32 and %I64. They
were added (for certain platforms) in late 2013 in an effort to make our
functions compatible with some windows implementations. curl has never used
them and they're not documented to work. I don't see a point for us to keep
them.

3.

I'd like to hear your ideas of more things to trim or otherwise make it run
faster. The two simple removals mentioned above made my test loop execution
time shrink down to 86% of the original time it took to run.

The idea is to focus on the "typical case".

PULL REQUEST

The above mentioned changes are available for review/test/public ridicule
here:

  https://github.com/curl/curl/pull/1981

Comments and feedback are welcome either here or in the PR itself!

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html