"When you come to a fork in the road, take it." - Yogi Berra [1]

Several times I've watch the project struggle with a desired libcurl
behavioral change due to concerns about backward compatibility. Currently,
there is a discussion about SSL host verification [2] which has this feel. I
would like to humbly suggest a way to allow changes to occur and yet
minimize the impact on existing application code, all the way back to the
source level.

I propose some way to tell libcurl what libcurl version the application was
coded for so that developers have the option to preserve old behavior when
making a change. This would protect applications at two levels: being run
against a newer library binary (likely to happen in the field with a system
update?) and if the application itself is recompiled against a newer libcurl
without any review of possible changes in libcurl and corresponding source
changes.

For example, if I coded something last year against libcurl 7.55.1,
somewhere early on there might be a call like:

    curl_coded_for_version(0x075501);

Setting zero would mean full current functionality (default). Setting
LIBCURL_VERSION_NUM would stabilize at the version of the last source compile.

Assume, for the sake of this example, that it was decided that the best
resolution to the verification issue [2] was indeed to split out new codes.
This would likely break older code, but with the above in effect, the old
result would be returned. Even if there is no change in libcurl's behavior,
debug/verbose output could flag changed behavior.

I would envision libcurl taking advantage of this version knowledge in a
very sparing manner. The documentation of the feature would have lots of
weaselly words:

<<
This function informs libcurl of the version of libcurl the application was
developed against with the goal of possibly providing backwards compatible
behavior in the rare case where developers feel the need to change a
behavior is important enough to risk possibly causing problems for existing
code. An example might be creating a new result code for a sub-case of an
existing code.

This is not a 'time-machine' function that will make libcurl behave like an
older version. In general, it will have no effect on added (superset)
features and will not necessarily apply to changes considered necessary
bugfixes. It's use is expected to be minimal and at the discretion of
libcurl developers. Any behavioral switching will be clearly documented on
the appropriate man pages. It is offered as an additional layer of
protection against changes that sometimes must occur.
>>

Of course, there's the problem of all the stuff out there that doesn't have
this...

Perhaps this could be part of a curl_global_initv(long flags, ...) function
taking variable arguments which must follow in a defined order of flags
which need arguments:

CURL_GLOBAL_CODED_FOR_VERSION - a version argument must follow
CURL_GLOBAL_MEM_ALLOC - pointers memory allocator functions follow.
CURL_GLOBAL_SAFE_ERASE - pointer to a secure erase function follow.

so

curl_global_initv(CURL_GLOBAL_DEFAULT |
  CURL_GLOBAL_CODED_FOR_VERSION |
  CURL_GLOBAL_MEM_ALLOC,
  CURL_GLOBAL_SAFE_ERASE,
  /• ver */ 0x075501,
  /• mem •/ malloc_fn, free_fn, realloc_fn, strdup_fn, calloc_fn,
  /* erase */ safe_erase_fn);

would be like an extended version of curl_global_init_mem() which also
establishes coded for version and a safe erase function.

Well, enough for now... Just some thoughts.

Cheers!
Rich

[1] https://ftw.usatoday.com/2015/09/the-50-greatest-yogi-berra-quotes
[2] https://curl.haxx.se//mail/lib-2018-10/0084.html (weird path)

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-10-29