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. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
