curl.h: convert CURLUSESSL* names to defines #16539
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
So that we can use L suffix. Follow-up to 2ec0037
This was referenced Mar 5, 2025
pps83
pushed a commit
to pps83/curl
that referenced
this pull request
Apr 26, 2025
So that we can use L suffix. Follow-up to 2ec0037 Closes curl#16539
pps83
pushed a commit
to pps83/curl
that referenced
this pull request
Apr 26, 2025
It fixes tests 1539, and 2402, 2404 (for non-Secure Transport), on macOS with the gcc compiler. Also unignore these tests in GHA/macos for non-secure transport. Ref: c349bd6 curl#14097 (issue 15.) Ref: 7b0240c curl#16539 Ref: 2ec0037 curl#16482 Closes curl#16580
pps83
pushed a commit
to pps83/curl
that referenced
this pull request
Apr 26, 2025
To fix this test on macOS with the gcc compiler. Also unignore test 1156 in GHA/macos. Ref: c349bd6 curl#14097 (issue 15.) Ref: 7b0240c curl#16539 Ref: 2ec0037 curl#16482 Closes curl#16579
chrisd8088
added a commit
to chrisd8088/git-lfs
that referenced
this pull request
Apr 27, 2025
Our macOS CI jobs execute on GitHub Actions runners, and in our "build-earliest" job we compile a custom version of Git and run our test suite with that version, which at the moment is Git v2.0.0. We compile our custom version of Git against the version of the curl library supplied by Homebrew on macOS GitHub Actions runners. Recently, after Homebrew updated its version of curl to 8.13.0, our "build-earliest" job been failing because the C compiler reports that the CURLUSESSL_TRY identifier is not declared in the call to curl_easy_setopt() in Git's get_curl_handle() function: https://github.com/git/git/blob/v2.0.0/http.c#L363 Between Git versions 1.8.3 and 2.33.8, that curl_easy_setopt() call would only be compiled if the CURLOPT_USE_SSL macro was defined. Fortunately, so long as curl v7.17.0 or later was in use, this was always the case, but only because Git itself defined that macro, not curl. Under the same conditions and between the same Git versions, Git also defined the CURLUSESSL_TRY macro that is now causing problems when we try to compile Git v2.0.0 with curl v8.13.0. Starting with commit git/git@4bc444e in Git v1.8.3, Git's http.h source file included macro definitions of the CURLOPT_USE_SSL and CURLUSESSL_TRY names. These were set to the values CURLOPT_FTP_SSL and CURLFTPSSL_TRY, respectively, so long as the CURLOPT_USE_SSL macro name was not defined elsewhere and the CURLOPT_FTP_SSL name was defined: https://github.com/git/git/blob/v1.8.3/http.h#L45-L52 https://github.com/git/git/blob/v2.0.0/http.h#L44-L51 These macro definitions were preceded with the following comment: CURLOPT_USE_SSL was known as CURLOPT_FTP_SSL up to 7.16.4, and the constants were known as CURLFTPSSL_* This comment specifically refers to the introduction to the curl library of the CURLOPT_USE_SSL CURLoption enumerated constant in commit curl/curl@9f44a95, and the introduction of the associated CURLUSESSL_TRY curl_usessl enumerated constant in commit curl/curl@3fa6016. Both of these constants first appeared in curl v7.17.0, and replaced the earlier CURLOPT_FTP_SSL CURLoption enumerated constant and CURLFTPSSL_TRY curl_ftpssl enumerated constant, which were retained but were now defined using macros that mapped those names to the corresponding new identifiers: https://github.com/curl/curl/blob/curl-7_17_0/include/curl/curl.h#L1140 https://github.com/curl/curl/blob/curl-7_17_0/include/curl/curl.h#L510 Thus the intention of the macro block added to Git's http.h source file in Git v1.8.3 was to check whether the new, generic CURLOPT_USE_SSL option and associated CURLUSESSL_TRY curl_usessl enumerated constant were defined, and they were not, define them in terms of their older FTP-specific counterparts, if those are available. However, curl has never defined identifiers such as CURLOPT_FTP_SSL as macros. Instead, macros named T(), CINIT(), and lately CURLOPT() have been used to initialize the CURLOPT_* CURLoption enumerated constants. See, for example: https://github.com/curl/curl/blob/curl-7_2/include/curl/curl.h#L172-L175 https://github.com/curl/curl/blob/curl-7_17_0/include/curl/curl.h#L573-L582 https://github.com/curl/curl/blob/curl-7_69_0/include/curl/curl.h#L948 These macros generate single enumerated constant assignments of the form: CURLOPT_USE_SSL = CURLOPTTYPE_LONG + 119 In other words, CURLOPT_USE_SSL has never been the name of a preprocessor macro, and CURLOPT_FTP_SSL was not either until curl v7.17.0 when it was redefined as a macro with the value CURLOPT_USE_SSL. Thus the first condition in the conditional statement of Git's macro block, namely !defined(CURLOPT_USE_SSL), has presumably never had its intended effect because CURLOPT_USE_SSL has never been the name of a macro. The defined() macro operator only evaluates to true if the name it is passed is defined as a macro, not as a regular C language identifier. Thus the expression !defined(CURLOPT_USE_SSL) would always be true, since CURLOPT_USE_SSL has never been defined as a macro. This means that other condition in Git's conditional statement, defined(CURLOPT_FTP_SSL), exclusively controlled whether the block was processed or not. As mentioned above, since v7.17.0 curl has defined CURLOPT_FTP_SSL as a macro, not an enumerated constant, so the conditional would evaluate to true and the macro definitions in the block would be processed. Hence with curl v7.17.0 or above, Git would define the macros CURLOPT_USE_SSL and CURLUSESSL_TRY with the values CURLOPT_FTP_SSL and CURLFTPSSL_TRY, and the preprocessor would expand those names to those values. But because those values match macros defined by curl, the preprocessor would expand them again, producing the values CURLOPT_USE_SSL and CURLUSESSL_TRY, which are of course identical to the names Git initially defined as macros. However, the C preprocessor does not expand macros it has expanded previously, to avoid infinite loops of expansions. Per the GCC manual: "If a macro x expands to use a macro y, and the expansion of y refers to the macro x, that is an indirect self-reference of x. x is not expanded in this case either." https://gcc.gnu.org/onlinedocs/cpp/Self-Referential-Macros.html Fortunately, both CURLOPT_USE_SSL and CURLUSESSL_TRY are defined by curl (since v7.17.0) as enumerated constants for the CURLoption and curl_usessl types, respectively: https://github.com/curl/curl/blob/curl-7_17_0/include/curl/curl.h#L1008 https://github.com/curl/curl/blob/curl-7_17_0/include/curl/curl.h#L497 So long as these names were ultimately defined by curl as non-macro identifiers, the compilation of older versions of Git that defined the macros CURLOPT_USE_SSL and CURLUSESSL_TRY would still succeed. This situation has changed with curl v8.13.0 because commit curl/curl@7b0240c replaced the CURLUSESSL_* enumerated constants, including CURLUSESSL_TRY, with macro definitions, for the reasons outlined in curl/curl#16539 and curl/curl#16482: https://github.com/curl/curl/blob/curl-8_13_0/include/curl/curl.h#L931 The consequence for our "build-earliest" CI job is that with curl updated to v8.13.0, as is now the case for the Homebrew version of curl installed on macOS GitHub Actions runners, there are two conflicting definitions of the CURLUSESSL_TRY macro. The first definition now appears in curl's header file, and as described above, older versions of Git provide another definition in a macro block in the http.h source file, and that block is processed because its conditional evaluates to true. The duplicate definitions of the CURLUSESSL_TRY macro only produce compiler warnings, in and of themselves. However, Git's definition supersedes curl's, and so the preprocessor first expands CURLUSESSL_TRY to CURLFTPSSL_TRY (per Git's definition) and then expands CURLFTPSSL_TRY back to CURLUSESSL_TRY (per curl's definition of CURLFTPSSL_TRY). At this point, preprocessing stops, at which point the compiler expects to find a C identifier with the name CURLUSESSL_TRY. When it finds none, an error results. (Note that newer versions of Git do not define the CURLOPT_USE_SSL and CURLUSESSL_TRY macros at all, so our other CI jobs are not affected by the changes in curl v8.13.0. The conditional block which defined these macros was removed from Git's http.h source file in commit git/git@5db9d38 of Git v2.34.0.) To resolve the compiler error without raising our minimum supported and tested version of Git from 2.0.0 all the way to 2.34.0, we instead update our script/build-git script to patch older versions of Git's http.h source file and comment out the conditional block which defined the CURLOPT_USE_SSL and CURLUSESSL_TRY macros. Since all modern versions of curl define these identifiers, there is no need for Git to define them, and as noted above, Git versions since 2.34.0 do not do so.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So that we can use L suffix.
Follow-up to 2ec0037