Re: Viability of issue #15472 "CURLE_NOT_BUILT_IN" as a first contribution

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---39887073-185372362-1785487400=:601257
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Fri, 31 Jul 2026, Salman Alghamdi via curl-library wrote:

> I'm looking to make my first contribution to curl and was considering issue 
> #15472 "setting a disabled option should return CURLE_NOT_BUILT_IN instead 
> of CURLE_UNKNOWN_OPTION"
>
> I took a look through lib/setopt.c and found a few #else guarded branches 
> for disabled features that still fall through to CURLE_UNKNOWN_OPTION, while 
> the CURLOPT_STREAM_WEIGHT branch (USE_HTTP2/USE_HTTP3) already does this 
> correctly with CURLE_NOT_BUILT_IN. My plan would be to walk the rest of 
> setopt.c looking for the same pattern and fix them, and add proper tests to 
> build the code and verify the returend code

I have personally gone a little bit back and forth on how this should or could 
be done, which is also possibly why we still see a little of both takes in the 
code.

The *general idea* is that if an option is a known libcurl option but 
something in a specific build makes it not present, it should return 
CURLE_NOT_BUILT_IN. The option name/number was used correctly, it's just that 
this build has explcitly somehow opted to not support it.

Similarly, CURLE_UNKNOWN_OPTION would then mean that the option is truly not 
known. Perhaps because it was introduced in a later release what currently 
runs, or that a crazy value is provided etc.

However, and now comes the complicating factors: one of the primary reasons 
for users to disable features in a build is to reduce footprint (and 
complexity). Adding a lot of code to do better return codes is then counter to 
that idea.

We also tend to think of the default build options as the standard libcurl 
that most users use. Users who actively and by choice decides to strip down 
features actively select to take the narrow path and they are expected to then 
be able to handle what libcurl returns for the disabled options - if they are 
still used.

Lastly: for an application there is basically no difference between "not 
supported because it was disabled in the build" and "not supported because I 
use a too old libcurl". The option the user tries does not work in this 
libcurl build.

> a) is this still considered worth fixing, or has it been deprioritized?

I beleive the answer has to be something in line with: if we can clean this up 
in a way that is not a total sacrifize in code size or complexity, then I 
think it could be beneficial. But I can also add that I have not figure out 
any such take.

So yes there is a obvious risk that there will work done for this that we 
can't merge.

-- 

  / daniel.haxx.se || https://rock-solid.curl.dev
---39887073-185372362-1785487400=:601257
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

---39887073-185372362-1785487400=:601257--