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, <[email protected]> wrote: > Send curl-library mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: Param Reddy via curl-library <[email protected]> > Subject: Re: Using libcurl with boringssl > Message-ID: <[email protected]> > 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 <[email protected]> > To: libcurl hacking <[email protected]> > Subject: making speedier printfs > Message-ID: <[email protected]> > 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 <[email protected]> > To: ViDyAnAnD NiLLe via curl-library <[email protected]> > Subject: Re: Time spent in curl_easy_perform on reused connection > Message-ID: <[email protected]> > 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 > [email protected] > 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
