[squid-dev] [PATCH] Deletors for std::unique_ptr WAS: Re: Broken trunk after r14735

[Alex Rousskov]

On 07/30/2016 07:03 AM, Amos Jeffries wrote:
> On 30/07/2016 6:29 a.m., Alex Rousskov wrote:
>> On 07/29/2016 09:27 AM, Amos Jeffries wrote:
>>>>> typedef std::unique_ptr<BIO, std::function<decltype(BIO_free)>> BIO_Pointer;
>>
>>> I got this config parsing crash replicated here and tried a dozen or so
>>> combinations. It does seem to keep coming back to my earlier approach of
>>> using per-type Functors as the most reliable solution.


>> AFAICT, this is not a question of reliability, and we should not be
>> fixing this by trying various combination of typedef characters until we
>> find one that does not immediately crash Squid. We should figure out
>> _why_ trunk code does not work (and then fix it accordingly).


> Please clear your head of the notion that I'm tying things bindly or
> randomly.

You control those notions -- I am going by what you tell me. I can
rarely guess your state of mind unless you document it. The lack of the
problem cause description combined with phrases like "trying dozen or so
combinations", "seem to", "the most reliable solution" and other things
you have said, tell me that you do not know what the root of the problem
is and assume that this is a reliability problem (i.e., sometimes a
certain solution works and sometimes it does not).


> The difficulty as I mentioned already has been in finding a working
> solution that is easily used without risking future bugs from people
> misunderstanding the use of these Pointers. That is what I meant by
> "reliable".

AFAICT, you have not documented what the cause of the bug is and you
have used a vague "reliable" adjective without enough context to guess
one of its meanings, so blaming others for not knowing your state of
mind is rather unfair.


> You have previously assured me[1] that using std::function<declype(X)>
> was the way to go and would allow removal of the macros. That usage has
> turned out to cause the null derefernce.

I fully admit that my std::function suggestion was wrong. While my
suggestion and decltype discovery were a big step in the right
direction, I missed the fact that the default functor constructor needs
to create the right target which, AFAIK, std::function cannot do. If you
think that makes me responsible for the bugs in your patch (otherwise
why would you even mention that mistake?), I am not going to waste time
convincing you otherwise.

For the record, my suggestions did remove macros, and I gave no
assurances that they are the final/correct solution (only that they
compile in my tests).

A bigger problem here is that your attitude continues to present a
difficult dilemma for me: When you post bad code, do I simply downvote
it (and get blamed for being harsh and uncooperative while increasing
the risks that we all will have to suffer from the consequences of that
code being committed), or do I spend insane amounts of time trying to
improve it despite the resistance and frequent personal attacks (and
then get blamed for the bugs)? It is difficult to find the lesser evil
among these options!

Alex.