I disagree w.r.t. the positional arguments. They are essential for
internationalization, as the order of parameters is language-dependent.

On Oct 12, 2017 6:03 AM, <curl-library-request_at_cool.haxx.se> wrote:

> Send curl-library mailing list submissions to
> curl-library_at_cool.haxx.se
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://cool.haxx.se/cgi-bin/mailman/listinfo/curl-library
> or, via email, send a message with subject or body 'help' to
> curl-library-request_at_cool.haxx.se
>
> You can reach the person managing the list at
> curl-library-owner_at_cool.haxx.se
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of curl-library digest..."
>
>
> Today's Topics:
>
> 1. Re: Using libcurl with boringssl (Daniel Stenberg)
> 2. making speedier printfs (Daniel Stenberg)
> 3. Re: Time spent in curl_easy_perform on reused connection
> (Daniel Stenberg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 12 Oct 2017 07:58:56 +0200 (CEST)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: Param Reddy via curl-library <curl-library_at_cool.haxx.se>
> Subject: Re: Using libcurl with boringssl
> Message-ID: <alpine.DEB.2.20.1710120758210.711_at_tvnag.unkk.fr>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> On Wed, 11 Oct 2017, Param Reddy via curl-library wrote:
>
> > Hi, I am trying to use libcurl (7_56 release) with boringssl. Seems like
> > this is supported but I get compilation error at:
> > https://github.com/curl/curl/blob/curl-7_56_0/lib/vtls/openssl.c#L847
> > (RSA_flags not declared and RSA_METHOD_FLAG_NO_CHECK is not declared).
>
> I believe this is already fixed in git with this commit?
>
> https://github.com/curl/curl/commit/2dcc378381881a374289d
>
> --
>
> / daniel.haxx.se
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 12 Oct 2017 09:41:01 +0200 (CEST)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: libcurl hacking <curl-library_at_cool.haxx.se>
> Subject: making speedier printfs
> Message-ID: <alpine.DEB.2.20.1710120918350.711_at_tvnag.unkk.fr>
> Content-Type: text/plain; format=flowed; charset=US-ASCII
>
> 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
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 12 Oct 2017 10:53:23 +0200 (CEST)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: ViDyAnAnD NiLLe via curl-library <curl-library_at_cool.haxx.se>
> Subject: Re: Time spent in curl_easy_perform on reused connection
> Message-ID: <alpine.DEB.2.20.1710121029480.711_at_tvnag.unkk.fr>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> On Wed, 11 Oct 2017, ViDyAnAnD NiLLe via curl-library wrote:
>
> > In second case(connection reuse) data function is always called after
> 40ms
> > of header callback function.
> >
> > What could be reason for data callback function getting called after
> 40ms of
> > consistent delay? I have tried it many times and behavior is same.
>
> When the headers have started to arrive, it is really a matter of the
> stream
> of data to come as fast as possible from the server. The headers and body
> arrive on the same TCP stream and if there's a time gap between the headers
> and the body in one case and not in the other, I can't think of any
> explanation for this in libcurl.
>
> I suspect that if you monitor the streams with wireshark or similar, you'll
> note that the gap is visible on the wire.
>
> --
>
> / daniel.haxx.se
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> curl-library mailing list
> curl-library_at_cool.haxx.se
> https://cool.haxx.se/cgi-bin/mailman/listinfo/curl-library
>
>
> ------------------------------
>
> End of curl-library Digest, Vol 146, Issue 12
> *********************************************
>

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-10-14