On Mon, 29 Oct 2012, Oscar Koeroo wrote:

> With respect to the option 1 provided from the application; I can only see
> four migration paths of choices in this:
> a. treat a 1 as a 0, forced debug mode
> b. treat a 1 as a 2, forced secure connection
> c. arbitrate per SSL backend what best to do. For GnuTLS that means
> treat a 1 as a 2, but for other SSL backends, treat it as a 0.
> d. treat a 1 as an error and force people to change their code.

...

> Given the paper option b is best and frankly I favor this.

I don't because of what I already explained: Making 1 silently equal 2 will
encourage people using the fixed libcurl to keep using 1 (or TRUE) as value,
and then the copy-and-paste people will use such code on older libcurl
versions as well and then they're back on the problematic route. It might even
make the problem worse!

I still advocate (d), but note that a large amount of programs don't check
return codes so they won't notice and will just move on and use the default
instead which is 2. An error is the only way that actually will push (some)
people to replacing the 1s with 2s or 0s. Also, as has been discussed already,
the number of programs that use 1 as a value is limited.

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