On Fri, 17 Feb 2017, Andreas Mohr wrote:

> This issue might be an incentive to review usual coding behaviour, to try to
> further identify/follow Best Practice.

Agreed. I think all bugs that slip in provide reasons for contemplating around
our processes and what we can do to improve.

But we're limited by the number of persons available for writing code,
reviewing patches and commenting on changes, so we need to find the right
balance. I think we usually weigh development vs safety decently good, but I
recognize that we could go an even safer route if we'd do less new development
and added less features. But that would also be very boring and make curl less
attractive to those who like the features. A balance.

If you have specific suggestions on how to improve our flow or our code, feel
free to suggest them. What kind of script/rule/filter can we add to detect
and avoid future mistakes of this kind?

I maintain that this particular mistake was unusually nasty in the way the
code isn't used in debug builds, I basically never do anything else *plus* the
valgrind reports were hidden due to other mistakes. So, an unfortunate series
of bad things that all occured that made us not discover this in time. But it
could also be noted that we *did* find and fix the problem only hours after
the release that introduced the mistake...

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