romenskiy2012/curl
1
0
Fork 0
mirror of https://github.com/curl/curl.git synced 2026-07-15 18:37:15 +03:00
Code Issues Projects Releases Packages Wiki Activity

tidy-up: miscellaneous

Browse source 
- tool_bname: scope an include.
- `endif` comments.
- Markdown fixes.
- comment tidy-ups.
- whitespace, newlines, indent.

Closes #20309
This commit is contained in:
Viktor Szakats 2026-01-02 01:34:05 +01:00
parent 62ba3604dc
commit ac6264366f
No known key found for this signature in database
GPG key ID: B5ABD165E2AEF201
98 changed files with 829 additions and 863 deletions
Download patch file Download diff file Expand all files Collapse all files

32
docs/tests/CI.md
View file

@ -11,13 +11,13 @@ large number of test suites.
Every pull request is verified for each of the following:
- it still builds, warning-free, on Linux, macOS, Windows, BSDs, with both
clang and gcc, autotools and cmake, out-of-tree and in-tree.
- it still builds fine on Windows with all supported MSVC versions
- it follows rudimentary code style rules
- the test suite still runs 100% fine
- the release tarball (the "dist") still works
- different TLS backends and options still compile and pass tests
- it still builds, warning-free, on Linux, macOS, Windows, BSDs, with both
clang and gcc, autotools and cmake, out-of-tree and in-tree.
- it still builds fine on Windows with all supported MSVC versions
- it follows rudimentary code style rules
- the test suite still runs 100% fine
- the release tarball (the "dist") still works
- different TLS backends and options still compile and pass tests
If the pull-request fails one of these tests, it shows up as a red X and you
are expected to fix the problem. If you do not understand what the issue is or
@ -26,15 +26,15 @@ can likely help out.
Consider the following table while looking at pull request failures:
| CI platform as shown in PR | State | What to look at next |
| ----------------------------------- | ------ | -------------------------- |
| Linux / macOS / Windows / ... | stable | all errors and failures |
| Fuzzer | stable | fuzzing results |
| Code analyzers | stable | new findings |
| checkdocs / checksrc / dist / ... | stable | all errors and failures |
| AppVeyor | stable | all errors and failures |
| buildbot/curl_Schannel ... | stable | all errors and failures |
| curl.curl (linux ...) | stable | all errors and failures |
| CI platform as shown in PR | State | What to look at next |
| ----------------------------------- | ------ | -------------------------- |
| Linux / macOS / Windows / ... | stable | all errors and failures |
| Fuzzer | stable | fuzzing results |
| Code analyzers | stable | new findings |
| checkdocs / checksrc / dist / ... | stable | all errors and failures |
| AppVeyor | stable | all errors and failures |
| buildbot/curl_Schannel ... | stable | all errors and failures |
| curl.curl (linux ...) | stable | all errors and failures |
Sometimes the tests fail or run slowly due to a dependency service temporarily
having issues, for example package downloads, or virtualized (non-native)

16
docs/tests/FILEFORMAT.md
View file

@ -302,14 +302,14 @@ test file to load the list content.
Send back this contents instead of the `<data>` one. The `NUM` is set by:
- The test number in the request line is >10000 and this is the remainder
of [test case number]%10000.
- The request was HTTP and included digest details, which adds 1000 to `NUM`
- If an HTTP request is NTLM type-1, it adds 1001 to `NUM`
- If an HTTP request is NTLM type-3, it adds 1002 to `NUM`
- If an HTTP request is Basic and `NUM` is already >=1000, it adds 1 to `NUM`
- If an HTTP request is Negotiate, `NUM` gets incremented by one for each
request with Negotiate authorization header on the same test case.
- The test number in the request line is >10000 and this is the remainder of
[test case number]%10000.
- The request was HTTP and included digest details, which adds 1000 to `NUM`
- If an HTTP request is NTLM type-1, it adds 1001 to `NUM`
- If an HTTP request is NTLM type-3, it adds 1002 to `NUM`
- If an HTTP request is Basic and `NUM` is already >=1000, it adds 1 to `NUM`
- If an HTTP request is Negotiate, `NUM` gets incremented by one for each
request with Negotiate authorization header on the same test case.
Dynamically changing `NUM` in this way allows the test harness to be used to
test authentication negotiation where several different requests must be sent