Hi Junio, On Thu, 7 Nov 2019, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Wed, 6 Nov 2019, Junio C Hamano wrote: > > > >> > presence of custom allocators, cURL would attempt to use the wrong > >> > allocator to release the memory. > >> > >> s/allocator/de&/; perhaps, even though it is clear enough from the > >> context, so it is probably OK as is. > >> > >> > A naïve attempt at fixing this would move the call to > >> > `curl_global_init()` _before_ the config is parsed (i.e. before that > >> > call to `slist_append()`). > >> > > >> > However, that does work, as we _also_ parse the config setting > >> > >> s/does work/does not work/; presumably? > > > > Indeed. Could I ask you to fix up locally, or do you want me to send a > > new revision of the patch? > > You can certainly tell me to locally tweak, but you'd need to be > more specific when some of my suggestions were "perhaps" (aka "you > could do it this way, which may be better, but I do not care too > deeply---I am OK with whichever you chooose after you (re)think > about it, but I am not choosing for you"). Right, I should have been more specific. > For now, I'll do the "does not work" thing only. Thanks! FWIW I would like to stick with "custom allocator" because even releasing the memory is the duty of an "allocator", even if that allocator happens to "deallocate" at that point what it has allocated before. Ciao, Dscho
