Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Viability of issue #15472 "CURLE_NOT_BUILT_IN" as a first contribution
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 31 Jul 2026 10:43:20 +0200 (CEST)
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.
Date: Fri, 31 Jul 2026 10:43:20 +0200 (CEST)
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
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-07-31