13f48dfb52
Daniel Stenberg
2026-03-07
Subject
docs: avoid starting sentences with However,
Binary
No binary (build failed)
Architecture & Compiler Flags
—
Build Log
(log yok)
Commit Diff GitHub →
.github/scripts/badwords.txt +1 -0docs/CIPHERS.md +3 -4docs/FAQ.md +3 -3docs/GOVERNANCE.md +1 -1docs/INSTALL.md +5 -5docs/KNOWN_BUGS.md +2 -2docs/TODO.md +8 -8docs/URL-SYNTAX.md +3 -3docs/cmdline-opts/_OPTIONS.md +2 -2docs/cmdline-opts/doh-url.md +3 -3docs/cmdline-opts/post301.md +3 -3docs/cmdline-opts/post302.md +3 -3docs/cmdline-opts/tcp-nodelay.md +3 -4docs/cmdline-opts/verbose.md +4 -5docs/examples/usercertinmem.c +5 -4docs/internals/CLIENT-READERS.md +2 -2docs/internals/MID.md +3 -3docs/internals/TLS-SESSIONS.md +2 -3docs/libcurl/curl_ws_start_frame.md +7 -8docs/libcurl/libcurl-security.md +6 -6docs/libcurl/libcurl-tutorial.md +13 -14docs/libcurl/libcurl.md +4 -4docs/libcurl/opts/CURLOPT_MAIL_AUTH.md +2 -3docs/libcurl/opts/CURLOPT_MAIL_RCPT.md +2 -2docs/libcurl/opts/CURLOPT_POSTREDIR.md +3 -3docs/libcurl/opts/CURLOPT_TCP_NODELAY.md +3 -4lib/bufq.h +6 -7lib/config-os400.h +1 -1lib/cookie.c +4 -4lib/curlx/fopen.c +2 -2lib/http.c +4 -5lib/http2.c +3 -4lib/url.c +3 -3lib/vauth/krb5_gssapi.c +2 -2lib/vauth/krb5_sspi.c +2 -2lib/vtls/vtls_scache.c +3 -4
.github/scripts/badwords.txt+1 -0
| @@ -94,3 +94,4 @@ file names\b:filenames | |
| \bmanpage[^si./;=&{:-]:man page | |
| favour:favor | |
| basically:rephrase? | |
| + | However,:rephrase? |
docs/CIPHERS.md+3 -4
| @@ -110,10 +110,9 @@ TLS 1.2 cipher suites with curl it is recommended that you use OpenSSL names | |
| as these are most widely recognized by the supported SSL backends. | |
| The complete list of cipher suites that may be considered for the `--ciphers` | |
| - | option is extensive, it consists of more than 300 ciphers suites. However, |
| - | nowadays for most of them their usage is discouraged, and support for a lot of |
| - | them have been removed from the various SSL backends, if ever implemented at |
| - | all. |
| + | option is extensive, it consists of more than 300 ciphers suites. Nowadays, |
| + | most of them are discouraged, and support for a lot of them has been removed |
| + | from the various SSL backends, if ever implemented at all. |
| A shortened list (based on [recommendations by | |
| Mozilla](https://wiki.mozilla.org/Security/Server_Side_TLS)) of cipher suites, | |
docs/FAQ.md+3 -3
| @@ -873,9 +873,9 @@ request body) use the `Expect: 100-continue` header. This header allows the | |
| server to deny the operation early so that libcurl can bail out before having | |
| to send any data. This is useful in authentication cases and others. | |
| - | However, many servers do not implement the `Expect:` stuff properly and if the |
| - | server does not respond (positively) within 1 second libcurl will continue and |
| - | send off the data anyway. |
| + | Many servers do not implement the `Expect:` stuff properly and if the server |
| + | does not respond (positively) within 1 second libcurl will continue and send |
| + | off the data anyway. |
| You can disable libcurl's use of the `Expect:` header the same way you disable | |
| any header, using `-H` / `CURLOPT_HTTPHEADER`, or by forcing it to use HTTP | |
docs/GOVERNANCE.md+1 -1
| @@ -61,7 +61,7 @@ they can be mentioned on the Sponsors page on the curl website. | |
| The curl project does not do or offer commercial support. It only hosts | |
| mailing lists, runs bug trackers etc to facilitate communication and work. | |
| - | However, Daniel works for wolfSSL and we offer commercial curl support there. |
| + | Daniel works for wolfSSL, which offers commercial curl support. |
| # Key roles | |
docs/INSTALL.md+5 -5
| @@ -418,11 +418,11 @@ for dynamic import symbols. | |
| ## Legacy Windows and SSL | |
| - | Schannel (from Windows SSPI), is the native SSL library in Windows. However, |
| - | Schannel in Windows <= XP is unable to connect to servers that no longer |
| - | support the legacy handshakes and algorithms used by those versions. If you |
| - | are using curl in one of those earlier versions of Windows you should choose |
| - | another SSL backend such as OpenSSL. |
| + | Schannel (from Windows SSPI), is the native SSL library in Windows. Schannel |
| + | in Windows <= XP is unable to connect to servers that no longer support the |
| + | legacy handshakes and algorithms used by those versions. If you are using curl |
| + | in one of those earlier versions of Windows you should choose another SSL |
| + | backend such as OpenSSL. |
| # Android | |
docs/KNOWN_BUGS.md+2 -2
| @@ -147,8 +147,8 @@ See [curl issue 6972](https://github.com/curl/curl/issues/6972) | |
| ## long paths are not fully supported on Windows | |
| curl on Windows cannot access long paths (paths longer than 260 characters). | |
| - | However, as a workaround, the Windows path prefix `\\?\` which disables all |
| - | path interpretation may work to allow curl to access the path. For example: |
| + | As a workaround, the Windows path prefix `\\?\` which disables all path |
| + | interpretation may work to allow curl to access the path. For example: |
| `\\?\c:\longpath`. | |
| See [curl issue 8361](https://github.com/curl/curl/issues/8361) | |
docs/TODO.md+8 -8
| @@ -67,10 +67,10 @@ does not have `res_init()` or an alternative. | |
| ## c-ares and CURLOPT_OPENSOCKETFUNCTION | |
| curl creates most sockets via the CURLOPT_OPENSOCKETFUNCTION callback and | |
| - | close them with the CURLOPT_CLOSESOCKETFUNCTION callback. However, c-ares does |
| - | not use those functions and instead opens and closes the sockets itself. This |
| - | means that when curl passes the c-ares socket to the CURLMOPT_SOCKETFUNCTION |
| - | it is not owned by the application like other sockets. |
| + | close them with the CURLOPT_CLOSESOCKETFUNCTION callback. c-ares does not use |
| + | those functions and instead opens and closes the sockets itself. This means |
| + | that when curl passes the c-ares socket to the CURLMOPT_SOCKETFUNCTION it is |
| + | not owned by the application like other sockets. |
| See [curl issue 2734](https://github.com/curl/curl/issues/2734) | |
| @@ -409,10 +409,10 @@ capabilities returned from the CAPABILITY command. | |
| ## SASL based authentication mechanisms | |
| Currently the LDAP module only supports `ldap_simple_bind_s()` in order to | |
| - | bind to an LDAP server. However, this function sends username and password |
| - | details using the simple authentication mechanism (as clear text). However, it |
| - | should be possible to use `ldap_bind_s()` instead specifying the security |
| - | context information ourselves. |
| + | bind to an LDAP server. This function sends username and password details |
| + | using the simple authentication mechanism (as clear text). It should be |
| + | possible to use `ldap_bind_s()` instead specifying the security context |
| + | information ourselves. |
| ## `CURLOPT_SSL_CTX_FUNCTION` for LDAPS | |
docs/URL-SYNTAX.md+3 -3
| @@ -374,9 +374,9 @@ curl supports SMB version 1 (only) | |
| The path part of an SMTP request specifies the hostname to present during | |
| communication with the mail server. If the path is omitted, then libcurl | |
| - | attempts to resolve the local computer's hostname. However, this may not |
| - | return the fully qualified domain name that is required by some mail servers |
| - | and specifying this path allows you to set an alternative name, such as your |
| + | attempts to resolve the local computer's hostname. This may not return the |
| + | fully qualified domain name that is required by some mail servers and |
| + | specifying this path allows you to set an alternative name, such as your |
| machine's fully qualified domain name, which you might have obtained from an | |
| external function such as gethostname or getaddrinfo. | |
docs/cmdline-opts/_OPTIONS.md+2 -2
| @@ -17,8 +17,8 @@ options *-O*, *-L* and *-v* at once as *-OLv*. | |
| In general, all boolean options are enabled with --**option** and yet again | |
| disabled with --**no-**option. That is, you use the same option name but | |
| - | prefix it with `no-`. However, in this list we mostly only list and show the |
| - | --**option** version of them. |
| + | prefix it with `no-`. In this list we mostly show the --**option** version of |
| + | them. |
| When --next is used, it resets the parser state and you start again with a | |
| clean option state, except for the options that are global. Global options | |
docs/cmdline-opts/doh-url.md+3 -3
| @@ -21,9 +21,9 @@ Specify which DNS-over-HTTPS (DoH) server to use to resolve hostnames, instead | |
| of using the default name resolver mechanism. The URL must be HTTPS. | |
| Some SSL options that you set for your transfer also apply to DoH since the | |
| - | name lookups take place over SSL. However, the certificate verification |
| - | settings are not inherited but are controlled separately via --doh-insecure |
| - | and --doh-cert-status. |
| + | name lookups take place over SSL. The certificate verification settings are |
| + | not inherited but are controlled separately via --doh-insecure and |
| + | --doh-cert-status. |
| By default, DoH is bypassed when initially looking up DNS records of the DoH server. You can specify the IP address(es) of the DoH server with --resolve to avoid this. | |
docs/cmdline-opts/post301.md+3 -3
| @@ -19,6 +19,6 @@ Example: | |
| Respect RFC 7231/6.4.2 and do not convert POST requests into GET requests when | |
| following a 301 redirect. The non-RFC behavior is ubiquitous in web browsers, | |
| - | so curl does the conversion by default to maintain consistency. However, a |
| - | server may require a POST to remain a POST after such a redirection. This |
| - | option is meaningful only when using --location. |
| + | so curl does the conversion by default to maintain consistency. A server may |
| + | require a POST to remain a POST after such a redirection. This option is |
| + | meaningful only when using --location. |
docs/cmdline-opts/post302.md+3 -3
| @@ -19,6 +19,6 @@ Example: | |
| Respect RFC 7231/6.4.3 and do not convert POST requests into GET requests when | |
| following a 302 redirect. The non-RFC behavior is ubiquitous in web browsers, | |
| - | so curl does the conversion by default to maintain consistency. However, a |
| - | server may require a POST to remain a POST after such a redirection. This |
| - | option is meaningful only when using --location. |
| + | so curl does the conversion by default to maintain consistency. A server may |
| + | require a POST to remain a POST after such a redirection. This option is |
| + | meaningful only when using --location. |
docs/cmdline-opts/tcp-nodelay.md+3 -4
| @@ -22,10 +22,9 @@ this algorithm is to minimize the number of small packets on the network | |
| for the network). | |
| Maximizing the amount of data sent per TCP segment is good because it | |
| - | amortizes the overhead of the send. However, in some cases small segments may |
| - | need to be sent without delay. This is less efficient than sending larger |
| - | amounts of data at a time, and can contribute to congestion on the network if |
| - | overdone. |
| + | amortizes the overhead of the send. In some cases small segments may need to |
| + | be sent without delay. This is less efficient than sending larger amounts of |
| + | data at a time, and can contribute to congestion on the network if overdone. |
| curl sets this option by default and you need to explicitly switch it off if | |
| you do not want it on (added in 7.50.2). | |
docs/cmdline-opts/verbose.md+4 -5
| @@ -51,11 +51,10 @@ If you only want HTTP headers in the output, --show-headers or --dump-header | |
| might be more suitable options. | |
| Since curl 8.10, mentioning this option several times in the same argument | |
| - | increases the level of the trace output. However, as before, a single |
| - | --verbose or --no-verbose reverts any additions by previous `-vv` again. This |
| - | means that `-vv -v` is equivalent to a single -v. This avoids unwanted |
| - | verbosity when the option is mentioned in the command line *and* curl config |
| - | files. |
| + | increases the level of the trace output. As before, a single --verbose or |
| + | --no-verbose reverts any additions by previous `-vv` again. This means that |
| + | `-vv -v` is equivalent to a single -v. This avoids unwanted verbosity when the |
| + | option is mentioned in the command line *and* curl config files. |
| Using it twice, e.g. `-vv`, outputs time (--trace-time) and transfer ids | |
| (--trace-ids), as well as enabling tracing for all protocols (--trace-config | |
docs/examples/usercertinmem.c+5 -4
| @@ -25,10 +25,11 @@ | |
| * Use in-memory user certificate and private key and retrieve an HTTPS page. | |
| * </DESC> | |
| */ | |
| - | /* Written by Ishan SinghLevett, based on Theo Borm's cacertinmem.c. |
| - | * Note that to maintain simplicity this example does not use a CA certificate |
| - | * for peer verification. However, some form of peer verification |
| - | * must be used in real circumstances when a secure connection is required. |
| + | |
| + | /* Written by Ishan SinghLevett, based on Theo Borm's cacertinmem.c. Note that |
| + | * to maintain simplicity this example does not use a CA certificate for peer |
| + | * verification. Some form of peer verification must be used in real |
| + | * circumstances when a secure connection is required. |
| */ | |
| /* Requires: USE_OPENSSL */ | |
docs/internals/CLIENT-READERS.md+2 -2
| @@ -134,8 +134,8 @@ they need it and give `FALSE` of none does. | |
| Many protocols need to know the amount of bytes delivered by the client | |
| readers in advance. They may invoke `Curl_creader_total_length(data)` to | |
| - | retrieve that. However, not all reader chains know the exact value beforehand. |
| - | In that case, the call returns `-1` for "unknown". |
| + | retrieve that. Not all reader chains know the exact value beforehand. In that |
| + | case, the call returns `-1` for "unknown". |
| Even if the length of the "raw" data is known, the length that is send may | |
| not. Example: with option `--crlf` the uploaded content undergoes line-end | |
docs/internals/MID.md+3 -3
| @@ -27,9 +27,9 @@ An `mid` is an `unsigned int`. There are two reserved values: | |
| this value. They get it assigned again when removed from | |
| a multi handle. | |
| - | This makes potential range of `mid`s from `1` to `UINT_MAX - 1` *inside |
| - | the same multi handle at the same time*. However, the `multi->xfers` table |
| - | reuses `mid` values from previous transfers that have been removed. |
| + | This makes potential range of `mid`s from `1` to `UINT_MAX - 1` *inside the |
| + | same multi handle at the same time*. The `multi->xfers` table reuses `mid` |
| + | values from previous transfers that have been removed. |
| `multi->xfers` is created with an initial capacity. At the time of this | |
| writing that is `16` for "multi_easy" handles (used in `curl_easy_perform()` | |
docs/internals/TLS-SESSIONS.md+2 -3
| @@ -59,9 +59,8 @@ One important thing: peer keys do not contain confidential information. If you | |
| configure a client certificate or SRP authentication with username/password, | |
| these are not part of the peer key. | |
| - | However, peer keys carry the hostnames you use curl for. They *do* |
| - | leak the privacy of your communication. We recommend to *not* persist |
| - | peer keys for this reason. |
| + | Peer keys carry the hostnames you use curl for. They *do* leak the privacy of |
| + | your communication. We recommend to *not* persist peer keys for this reason. |
| **Caveat**: The key may contain filenames or paths. It does not reflect the | |
| *contents* in the file system. If you change `/etc/ssl/cert.pem` and reuse | |
docs/libcurl/curl_ws_start_frame.md+7 -8
| @@ -43,16 +43,15 @@ To send larger frames or frames of a different type, call | |
| curl_ws_start_frame() from within the read function and then return | |
| the data belonging to the frame. | |
| - | The function fails, if a previous frame has not been completely |
| - | read yet. Also it fails in *CURLWS_RAW_MODE*. |
| + | The function fails, if a previous frame has not been completely read yet. Also |
| + | it fails in *CURLWS_RAW_MODE*. |
| - | The read function in libcurl usually treats a return value of 0 |
| - | as the end of file indication and stops any further reads. This |
| - | would prevent sending WebSocket frames of length 0. |
| + | The read function in libcurl usually treats a return value of 0 as the end of |
| + | file indication and stops any further reads. This would prevent sending |
| + | WebSocket frames of length 0. |
| - | If the read function calls `curl_ws_start_frame()` however, a return |
| - | value of 0 is *not* treated as an end of file and libcurl calls |
| - | the read function again. |
| + | If the read function calls `curl_ws_start_frame()`, a return value of 0 is |
| + | *not* treated as an end of file and libcurl calls the read function again. |
| # FLAGS | |
docs/libcurl/libcurl-security.md+6 -6
| @@ -20,9 +20,9 @@ libcurl-security - security considerations when using libcurl | |
| The libcurl project takes security seriously. The library is written with | |
| caution and precautions are taken to mitigate many kinds of risks encountered | |
| while operating with potentially malicious servers on the Internet. It is a | |
| - | powerful library, however, which allows application writers to make trade-offs |
| - | between ease of writing and exposure to potential risky operations. If used |
| - | the right way, you can use libcurl to transfer data pretty safely. |
| + | powerful library that allows application writers to make trade-offs between |
| + | ease of writing and exposure to potential risky operations. If used the right |
| + | way, you can use libcurl to transfer data pretty safely. |
| Many applications are used in closed networks where users and servers can | |
| (possibly) be trusted, but many others are used on arbitrary servers and are | |
| @@ -287,9 +287,9 @@ When first realizing this, the curl team tried to filter out such attempts in | |
| order to protect applications for inadvertent probes of for example internal | |
| networks etc. This resulted in CVE-2019-15601 and the associated security fix. | |
| - | However, we have since been made aware of the fact that the previous fix was far |
| - | from adequate as there are several other ways to accomplish more or less the |
| - | same thing: accessing a remote host over the network instead of the local file |
| + | We have since been made aware of the fact that the previous fix was far from |
| + | adequate as there are several other ways to accomplish more or less the same |
| + | thing: accessing a remote host over the network instead of the local file |
| system. | |
| The conclusion we have come to is that this is a weakness or feature in the | |
docs/libcurl/libcurl-tutorial.md+13 -14
| @@ -772,10 +772,10 @@ terminal. | |
| Switch on the progress meter by, oddly enough, setting | |
| CURLOPT_NOPROGRESS(3) to zero. This option is set to 1 by default. | |
| - | For most applications however, the built-in progress meter is useless and what |
| - | instead is interesting is the ability to specify a progress callback. The |
| - | function pointer you pass to libcurl is then called on irregular intervals |
| - | with information about the current transfer. |
| + | For most applications, the built-in progress meter is useless and what instead |
| + | is interesting is the ability to specify a progress callback. The function |
| + | pointer you pass to libcurl is then called on irregular intervals with |
| + | information about the current transfer. |
| Set the progress callback by using CURLOPT_PROGRESSFUNCTION(3). Pass a pointer | |
| to a function that matches this prototype: | |
| @@ -1190,13 +1190,13 @@ CURLOPT_COOKIEFILE(3). | |
| The CURLOPT_COOKIEFILE(3) option also automatically enables the cookie parser | |
| in libcurl. Until the cookie parser is enabled, libcurl does not parse or | |
| - | understand incoming cookies and they are instead ignored. However, when the |
| - | parser is enabled the cookies are understood and the cookies are kept in |
| - | memory and used properly in subsequent requests when the same handle is used. |
| - | Many times this is enough, and you may not have to save the cookies to disk at |
| - | all. Note that the file you specify to CURLOPT_COOKIEFILE(3) does not have to |
| - | exist to enable the parser, so a common way to enable the parser and not read |
| - | any cookies is to use the name of a file you know does not exist. |
| + | understand incoming cookies and they are instead ignored. When the parser is |
| + | enabled the cookies are understood and the cookies are kept in memory and used |
| + | properly in subsequent requests when the same handle is used. Many times this |
| + | is enough, and you may not have to save the cookies to disk at all. Note that |
| + | the file you specify to CURLOPT_COOKIEFILE(3) does not have to exist to enable |
| + | the parser, so a common way to enable the parser and not read any cookies is |
| + | to use the name of a file you know does not exist. |
| If you would rather use existing cookies that you have previously received | |
| with your Netscape or Mozilla browsers, you can make libcurl use that cookie | |
| @@ -1446,9 +1446,8 @@ size. | |
| ## [2] | |
| - | This happens on Windows machines when libcurl is built and used as a |
| - | DLL. However, you can still do this on Windows if you link with a static |
| - | library. |
| + | This happens on Windows machines when libcurl is built and used as a DLL. You |
| + | can still do this on Windows if you link with a static library. |
| ## [3] | |
docs/libcurl/libcurl.md+4 -4
| @@ -233,10 +233,10 @@ parts of the program of which it is part. | |
| A special part of the global constant environment is the identity of the | |
| memory allocator. curl_global_init(3) selects the system default memory | |
| - | allocator, but you can use curl_global_init_mem(3) to supply one of your |
| - | own. However, there is no way to use curl_global_init_mem(3) in a |
| - | modular program -- all modules in the program that might use libcurl would |
| - | have to agree on one allocator. |
| + | allocator, but you can use curl_global_init_mem(3) to supply one of your own. |
| + | There is no way to use curl_global_init_mem(3) in a modular program -- all |
| + | modules in the program that might use libcurl would have to agree on one |
| + | allocator. |
| There is a failsafe in libcurl that makes it usable in simple situations | |
| without you having to worry about the global constant environment at all: | |
docs/libcurl/opts/CURLOPT_MAIL_AUTH.md+2 -3
| @@ -38,9 +38,8 @@ and the AUTH address is not known or is invalid, then an empty string should | |
| be used for this parameter. | |
| Unlike CURLOPT_MAIL_FROM(3) and CURLOPT_MAIL_RCPT(3), the address should not | |
| - | be specified within a pair of angled brackets (\<\>). However, if an empty |
| - | string is used then a pair of brackets are sent by libcurl as required by RFC |
| - | 2554. |
| + | be specified within a pair of angled brackets (\<\>). If an empty string is |
| + | used, a pair of brackets is sent by libcurl as required by RFC 2554. |
| The application does not have to keep the string around after setting this | |
| option. | |
docs/libcurl/opts/CURLOPT_MAIL_RCPT.md+2 -2
| @@ -36,8 +36,8 @@ libcurl does not copy the list, it needs to be kept around until after the | |
| transfer has completed. | |
| When performing a mail transfer, each recipient should be specified within a | |
| - | pair of angled brackets (\<\>), however, should you not use an angled bracket |
| - | as the first character libcurl assumes you provided a single email address and |
| + | pair of angled brackets (\<\>). Should you not use an angled bracket as the |
| + | first character, libcurl assumes you provided a single email address and |
| encloses that address within brackets for you. | |
| In order to specify DSN parameters (as per RFC 3461), the address has to be | |
docs/libcurl/opts/CURLOPT_POSTREDIR.md+3 -3
| @@ -41,9 +41,9 @@ after a 303 redirect. The value **CURL_REDIR_POST_ALL** is a convenience | |
| define that sets all three bits. | |
| The non-RFC behavior is ubiquitous in web browsers, so the library does the | |
| - | conversion by default to maintain consistency. However, a server may require a |
| - | POST to remain a POST after such a redirection. This option is meaningful only |
| - | when setting CURLOPT_FOLLOWLOCATION(3). |
| + | conversion by default to maintain consistency. A server may require a POST to |
| + | remain a POST after such a redirection. This option is meaningful only when |
| + | setting CURLOPT_FOLLOWLOCATION(3). |
| # DEFAULT | |
docs/libcurl/opts/CURLOPT_TCP_NODELAY.md+3 -4
| @@ -37,10 +37,9 @@ small packets on the network (where "small packets" means TCP segments less | |
| than the Maximum Segment Size for the network). | |
| Maximizing the amount of data sent per TCP segment is good because it | |
| - | amortizes the overhead of the send. However, in some cases small segments may |
| - | need to be sent without delay. This is less efficient than sending larger |
| - | amounts of data at a time, and can contribute to congestion on the network if |
| - | overdone. |
| + | amortizes the overhead of the send. In some cases small segments may need to |
| + | be sent without delay. This is less efficient than sending larger amounts of |
| + | data at a time, and can contribute to congestion on the network if overdone. |
| # DEFAULT | |
lib/bufq.h+6 -7
| @@ -44,9 +44,8 @@ struct buf_chunk { | |
| /** | |
| * A pool for providing/keeping a number of chunks of the same size | |
| * | |
| - | * The same pool can be shared by many `bufq` instances. However, a pool |
| - | * is not thread safe. All bufqs using it are supposed to operate in the |
| - | * same thread. |
| + | * The same pool can be shared by many `bufq` instances. A pool is not thread |
| + | * safe. All bufqs using it are supposed to operate in the same thread. |
| */ | |
| struct bufc_pool { | |
| struct buf_chunk *spare; /* list of available spare chunks */ | |
| @@ -77,10 +76,10 @@ void Curl_bufcp_free(struct bufc_pool *pool); | |
| * | |
| * By default, writing to a full bufq will return (-1, CURLE_AGAIN). Same | |
| * as reading from an empty bufq. | |
| - | * With `BUFQ_OPT_SOFT_LIMIT` set, a bufq will allow writing becond this |
| - | * limit and use more than `max_chunks`. However it will report that it |
| - | * is full nevertheless. This is provided for situation where writes |
| - | * preferably never fail (except for memory exhaustion). |
| + | * With `BUFQ_OPT_SOFT_LIMIT` set, a bufq will allow writing beyond this limit |
| + | * and use more than `max_chunks`. It will report that it is full |
| + | * nevertheless. This is provided for situation where writes preferably never |
| + | * fail (except for memory exhaustion). |
| * | |
| * By default and without a pool, a bufq will keep chunks that read | |
| * empty in its `spare` list. Option `BUFQ_OPT_NO_SPARES` will | |
lib/config-os400.h+1 -1
| @@ -37,7 +37,7 @@ | |
| /* OS400 supports a 3-argument ASCII version of gethostbyaddr_r(), but its | |
| * prototype is incompatible with the "standard" one (1st argument is not | |
| - | * const). However, getaddrinfo() is supported (ASCII version defined as |
| + | * const). getaddrinfo() is supported (ASCII version defined as |
| * a local wrapper in setup-os400.h) in a thread-safe way: we can then | |
| * configure getaddrinfo() as such and get rid of gethostbyname_r() without | |
| * loss of thread-safeness. */ | |
lib/cookie.c+4 -4
| @@ -287,10 +287,10 @@ static void remove_expired(struct CookieInfo *ci) | |
| /* | |
| * If the earliest expiration timestamp in the jar is in the future we can | |
| * skip scanning the whole jar and instead exit early as there will not be | |
| - | * any cookies to evict. If we need to evict however, reset the |
| - | * next_expiration counter in order to track the next one. In case the |
| - | * recorded first expiration is the max offset, then perform the safe |
| - | * fallback of checking all cookies. |
| + | * any cookies to evict. If we need to evict, reset the next_expiration |
| + | * counter in order to track the next one. In case the recorded first |
| + | * expiration is the max offset, then perform the safe fallback of checking |
| + | * all cookies. |
| */ | |
| if(now < ci->next_expiration && | |
| ci->next_expiration != CURL_OFF_T_MAX) | |
lib/curlx/fopen.c+2 -2
| @@ -439,8 +439,8 @@ int curlx_win32_stat(const char *path, curlx_struct_stat *buffer) | |
| #if !defined(CURL_DISABLE_HTTP) || !defined(CURL_DISABLE_COOKIES) || \ | |
| !defined(CURL_DISABLE_ALTSVC) | |
| /* rename() on Windows does not overwrite, so we cannot use it here. | |
| - | MoveFileEx() will overwrite and is usually atomic, however it fails |
| - | when there are open handles to the file. */ |
| + | MoveFileEx() will overwrite and is usually atomic but fails when there are |
| + | open handles to the file. */ |
| int curlx_win32_rename(const char *oldpath, const char *newpath) | |
| { | |
| int res = -1; /* fail */ | |
lib/http.c+4 -5
| @@ -3288,11 +3288,10 @@ static CURLcode http_header_c(struct Curl_easy *data, | |
| HD_VAL(hd, hdlen, "Content-Encoding:") : NULL; | |
| if(v) { | |
| /* | |
| - | * Process Content-Encoding. Look for the values: identity, |
| - | * gzip, deflate, compress, x-gzip and x-compress. x-gzip and |
| - | * x-compress are the same as gzip and compress. (Sec 3.5 RFC |
| - | * 2616). zlib cannot handle compress. However, errors are |
| - | * handled further down when the response body is processed |
| + | * Process Content-Encoding. Look for the values: identity, gzip, deflate, |
| + | * compress, x-gzip and x-compress. x-gzip and x-compress are the same as |
| + | * gzip and compress. (Sec 3.5 RFC 2616). zlib cannot handle compress. |
| + | * Errors are handled further down when the response body is processed |
| */ | |
| return Curl_build_unencoding_stack(data, v, FALSE); | |
| } | |
lib/http2.c+3 -4
| @@ -1889,10 +1889,9 @@ static CURLcode h2_progress_ingress(struct Curl_cfilter *cf, | |
| while(!ctx->conn_closed && Curl_bufq_is_empty(&ctx->inbufq)) { | |
| stream = H2_STREAM_CTX(ctx, data); | |
| if(stream && (stream->closed || !data_max_bytes)) { | |
| - | /* We would like to abort here and stop processing, so that |
| - | * the transfer loop can handle the data/close here. However, |
| - | * this may leave data in underlying buffers that will not |
| - | * be consumed. */ |
| + | /* We would like to abort here and stop processing, so that the transfer |
| + | * loop can handle the data/close here. This may leave data in |
| + | * underlying buffers that will not be consumed. */ |
| if(!cf->next || !cf->next->cft->has_data_pending(cf->next, data)) | |
| Curl_multi_mark_dirty(data); | |
| break; | |
lib/url.c+3 -3
| @@ -3520,9 +3520,9 @@ static CURLcode url_find_or_create_conn(struct Curl_easy *data) | |
| #endif | |
| } | |
| else { | |
| - | /* We have decided that we want a new connection. However, we may not |
| - | be able to do that if we have reached the limit of how many |
| - | connections we are allowed to open. */ |
| + | /* We have decided that we want a new connection. We may not be able to do |
| + | that if we have reached the limit of how many connections we are |
| + | allowed to open. */ |
| DEBUGF(infof(data, "new connection, bits.close=%d", needle->bits.close)); | |
| if(waitpipe) { | |
lib/vauth/krb5_gssapi.c+2 -2
| @@ -240,8 +240,8 @@ CURLcode Curl_auth_create_gssapi_security_message(struct Curl_easy *data, | |
| /* Process the maximum message size the server can receive */ | |
| if(max_size > 0) { | |
| - | /* The server has told us it supports a maximum receive buffer, however, as |
| - | we do not require one unless we are encrypting data, we tell the server |
| + | /* The server has told us it supports a maximum receive buffer, but as we |
| + | do not require one unless we are encrypting data, we tell the server |
| our receive buffer is zero. */ | |
| max_size = 0; | |
| } | |
lib/vauth/krb5_sspi.c+2 -2
| @@ -318,8 +318,8 @@ CURLcode Curl_auth_create_gssapi_security_message(struct Curl_easy *data, | |
| /* Process the maximum message size the server can receive */ | |
| if(max_size > 0) { | |
| - | /* The server has told us it supports a maximum receive buffer, however, as |
| - | we do not require one unless we are encrypting data, we tell the server |
| + | /* The server has told us it supports a maximum receive buffer, but as we |
| + | do not require one unless we are encrypting data, we tell the server |
| our receive buffer is zero. */ | |
| max_size = 0; | |
| } | |
lib/vtls/vtls_scache.c+3 -4
| @@ -73,10 +73,9 @@ static CURLcode cf_ssl_peer_key_add_path(struct dynbuf *buf, | |
| bool *is_local) | |
| { | |
| if(path && path[0]) { | |
| - | /* We try to add absolute paths, so that the session key can stay |
| - | * valid when used in another process with different CWD. However, |
| - | * when a path does not exist, this does not work. Then, we add |
| - | * the path as is. */ |
| + | /* We try to add absolute paths, so that the session key can stay valid |
| + | * when used in another process with different CWD. When a path does not |
| + | * exist, this does not work. Then, we add the path as is. */ |
| #ifdef _WIN32 | |
| char abspath[_MAX_PATH]; | |
| if(_fullpath(abspath, path, _MAX_PATH)) | |