On Tue, 2 Aug 2016, dev_user wrote:

> Excellent. I will watch for that. As I noted on my email 27th July 2016
> there seems to be a few tests that fail in various versions released over
> the past little while :

> 7.50.0 :TESTFAIL: These test cases failed: 1139 1140
>
> So hopefully 7.50.1 reports a 100% clear on the testsuite.

We run most of our autobuild tests directly from git, so for example these two
tests 1139 and 1140 will succeed off git but fail in a relase where we've
forgotten to include some files in the tarball - like we did in 7.50.0.

The lesson here is that we should perhaps have both 1139 and 1140 actually
work only on files that can be found in the makefiles (that would be included
in the dist) so that we can detect these problems earlier and easier. I
haven't really figured out the best approach.

In general though, all test failures are not alike. Failing these two
particular tests in a release for example is not a big deal (for me) as long
as they work in git.

>> Possibly most notable: we're reverting the change that modified the CURL,
>> CURLM and CURLSH types and they go back to be 'void *' unless you define
>> CURL_STRICTER before including our headers.
>
> That is interesting. I wonder if there is a test for that.

We don't have a test for that and really, the change only hit people and
applications that second-guessed what the types are and do their own forward
declarations of them instead of including our headers.

While I'm not sure we actually violated the API with this, it seemed at least
10 or so applications had code like this and I think that was too hard of a
blow for me to insist that we were right. Now at least "good" applications can
opt in to stricter type checks with this define.

> However I have to agree that there is no reason to promise or even suggest
> that curl "symbols are free for others to forward declare like that." I
> certainly don't have a compile or link problem and last time I checked I
> have 90,000+ lines of code to deal with inside my applications here. Not a
> single error.

I agree. I suspect a vast majority of all libcurl users had no problems at all
with that change. Still...

> Wish I could do more. I am sure you know that libcurl has become an
> essential component.

I'm aware => https://daniel.haxx.se/blog/2016/05/31/on-billions-and-users/

But libcurl sneaking into just about every device on the planet haven't made
our "dev team" to grow in the same speed...

> In an unrelated bug I have been living in my curl tee-shirt for more than a
> few days in a few offices and thus far received comments like:

> 4 - I tried that in front of a url in my browser and it doesn't
> do anything. [ I loved that one ]

That's lovely. We clearly hang out in different circles because when I've worn
my t-shirt I've had several people ask me if we have registered that URL
scheme (and yeah, I've toyed with the idea of putting an internet-draft
together for it...)! Several people on twitter also asked me if just two
slashes really are enough. =)

Unfortunately I've not yet received any curl stickers!

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