tidy-up: fix typos in docs and comments
No binary (build failed)
—
(log yok)
| @@ -7,8 +7,8 @@ | |
| matrix: | |
| - name: Markdown | |
| expect_match: false | |
| - | apsell: |
| - | mode: en |
| + | aspell: |
| + | lang: en |
| dictionary: | |
| wordlists: | |
| - wordlist.txt | |
| @@ -57,7 +57,7 @@ the three ones above are all 'no'. | |
| - Can the bug be fixed "easily" by applying a patch? | |
| - Does the bug break the build? Most users do not build curl themselves. | |
| - How long is it until the already scheduled next release? | |
| - | - Can affected users safely rather revert to a former release until the next |
| + | - Can affected users safely revert to a former release until the next |
| scheduled release? | |
| - Is it a performance regression with no functionality side-effects? If so it | |
| has to be substantial. | |
| @@ -702,10 +702,10 @@ RFC 6266 documents how UTF-8 names can be passed to a client in the | |
| [curl issue 1888](https://github.com/curl/curl/issues/1888) | |
| - | ## Option to make `-Z` merge lined based outputs on stdout |
| + | ## Option to make `-Z` merge line-based outputs on stdout |
| - | When a user requests multiple lined based files using `-Z` and sends them to |
| - | stdout, curl does not *merge* and send complete lines fine but may send |
| + | When a user requests multiple line-based files using `-Z` and sends them to |
| + | stdout, curl does not *merge* and send complete lines but may send |
| partial lines from several sources. | |
| [curl issue 5175](https://github.com/curl/curl/issues/5175) | |
| @@ -20,5 +20,5 @@ setup handshakes. This improves speed. Connection reuse can only be done for | |
| URLs specified for a single command line invocation and cannot be performed | |
| between separate curl runs. | |
| - | Everything provided on the command line that is not a command line option or |
| - | its argument, curl assumes is a URL and treats it as such. |
| + | curl assumes everything provided on the command line that is not a command |
| + | line option or its argument is a URL and treats it as such. |
| @@ -55,11 +55,11 @@ compared to the *previous* pollset. If relevant changes are detected, | |
| * a socket was also in the previous one, but IN/OUT flags changed | |
| * a socket in the previous one is no longer part of the current | |
| - | `multi_ev.c` keeps a `struct mev_sh_entry` for each sockets in a hash |
| + | `multi_ev.c` keeps a `struct mev_sh_entry` for each socket in a hash |
| with the socket as key. It tracks in each entry which transfers are | |
| - | interested in this particular socket. How many transfer want to read |
| - | and/or write and what the summarized `POLLIN/POLLOUT` action, that |
| - | had been reported to `multi->socket_cb` was. |
| + | interested in this particular socket, how many transfers want to read |
| + | and/or write and the summarized `POLLIN/POLLOUT` action reported to |
| + | `multi->socket_cb`. |
| This is necessary as a socket may be in use by several transfers | |
| at the same time (think HTTP/2 on the same connection). When a transfer | |
| @@ -57,12 +57,12 @@ A thread pool can be destroyed via `Curl_thrdpool_destroy(pool, join)` where | |
| ### Safety | |
| - | The thread pool operates use a mutex and condition variables to manage |
| + | The thread pool operates using a mutex and condition variables to manage |
| concurrency. All interactions and callback invocation are done under | |
| the pool's mutex lock, *except* the "process" callback which is invoked | |
| unlocked. | |
| - | To avoid deadlocks, no callback must invoked other pool functions. Also, |
| + | To avoid deadlocks, no callback must invoke other pool functions. Also, |
| any call of pool functions may result in callback invocations. | |
| The "work items", once "taken" by the pool, should not be referenced | |
| @@ -102,7 +102,7 @@ the queue. Calling `Curl_thrdq_recv()` delivers processed items back. | |
| ### Safety | |
| - | The thread queue operates use a mutex and condition variables to manage |
| + | The thread queue operates using a mutex and condition variables to manage |
| concurrency. All interactions and callback invocation are done under | |
| the queue's mutex lock, *except* the "process" callback which is invoked | |
| unlocked. | |
| @@ -25,7 +25,7 @@ this was mostly not noticeable. On slow machines or in CI, this led to rare | |
| and annoying test failures. | |
| (Especially when we added assertions that the reported "timeline" of a | |
| - | transfer was in the correct order: *queue -> nameloopup -> connect -> |
| + | transfer was in the correct order: *queue -> namelookup -> connect -> |
| appconnect ->...*.) | |
| ## Revised Approach | |
| @@ -54,8 +54,8 @@ stored in a home directory that is NFS mounted or used on another network | |
| based file system, so the clear text password flies through your network every | |
| time anyone reads that file. | |
| - | For applications that enable .netrc use, a user who manage to set the right |
| - | URL might then be possible to pass on passwords. |
| + | For applications that enable .netrc use, a user who manages to set the right |
| + | URL might then make it possible to pass on passwords. |
| To avoid these problems, do not use .netrc files and never store passwords in | |
| plain text anywhere. | |
| @@ -108,8 +108,8 @@ with it. | |
| # SET PARTS | |
| - | A user set individual URL parts, either after having parsed a full URL or |
| - | instead of parsing such. |
| + | A user can set individual URL parts, either after having parsed a full URL or |
| + | instead of parsing one. |
| ~~~c | |
| rc = curl_url_set(urlp, CURLUPART_FRAGMENT, "anchor", 0); | |
| @@ -43,12 +43,12 @@ multiple requests are done due to authentication, followed redirections or | |
| similar, they all get this cookie passed on. | |
| The cookies set by this option are separate from the internal cookie storage | |
| - | held by the cookie engine and they are not be modified by it. If you enable |
| + | held by the cookie engine and they are not modified by it. If you enable |
| the cookie engine and either you have imported a cookie of the same name (e.g. | |
| 'foo') or the server has set one, it has no effect on the cookies you set | |
| here. A request to the server sends both the 'foo' held by the cookie engine | |
| and the 'foo' held by this option. To set a cookie that is instead held by the | |
| - | cookie engine and can be modified by the server use CURLOPT_COOKIELIST(3). |
| + | cookie engine and can be modified by the server, use CURLOPT_COOKIELIST(3). |
| Since this custom cookie is appended to the Cookie: header in addition to any | |
| cookies set by the cookie engine, there is a risk that the header ends up too | |
| @@ -72,7 +72,7 @@ option. | |
| Using this option multiple times makes the last set string override the | |
| previous ones. Set it to NULL to disable its use again. Note however that | |
| - | libcurl needs a URL set to be able to performed a transfer. |
| + | libcurl needs a URL set to be able to perform a transfer. |
| The parser used for handling the URL set with CURLOPT_URL(3) is the same that | |
| curl_url_set(3) uses. | |
| @@ -1204,7 +1204,7 @@ static CURLcode cf_socket_open(struct Curl_cfilter *cf, | |
| ctx->started_at = *Curl_pgrs_now(data); | |
| #ifdef SOCK_NONBLOCK | |
| /* Do not tuck SOCK_NONBLOCK into socktype when opensocket callback is set | |
| - | * because we would not know how socketype is about to be used in the |
| + | * because we would not know how socktype is about to be used in the |
| * callback, SOCK_NONBLOCK might get factored out before calling socket(). | |
| */ | |
| if(!data->set.fopensocket) | |
| @@ -413,7 +413,7 @@ static CURLcode cw_out_do_write(struct cw_out_ctx *ctx, | |
| out: | |
| if(result) { | |
| - | /* We do not want to invoked client callbacks a second time after |
| + | /* We do not want to invoke client callbacks a second time after |
| * encountering an error. See issue #13337 */ | |
| ctx->errored = TRUE; | |
| cw_out_bufs_free(ctx); | |
| @@ -524,7 +524,7 @@ static bool http_should_fail(struct Curl_easy *data, int httpcode) | |
| /* | |
| * Examine the current authentication state to see if this is an error. The | |
| * idea is for this function to get called after processing all the headers | |
| - | * in a response message. If we have been to asked to authenticate |
| + | * in a response message. If we have been asked to authenticate at |
| * a particular stage, and we have done it, we are OK. If we are already | |
| * completely authenticated, it is not OK to get another 401 or 407. | |
| * | |
| @@ -86,7 +86,7 @@ typedef enum { | |
| /* This is the struct known as CURLM on the outside */ | |
| struct Curl_multi { | |
| - | /* First a simple identifier to easier detect if a user mix up |
| + | /* First a simple identifier to more easily detect if a user mixes up |
| this multi handle with an easy handle. | |
| Set this to CURLMULTI_MAGIC_NUMBER. */ | |
| uint32_t magic; | |
| @@ -1423,8 +1423,8 @@ static CURLcode smtp_state_rcpt_resp(struct Curl_easy *data, | |
| is_smtp_err = (smtpcode / 100 != 2); | |
| - | /* If there is multiple RCPT TO to be issued, it is possible to ignore errors |
| - | and proceed with only the valid addresses. */ |
| + | /* If there are multiple RCPT TO commands to issue, it is possible to |
| + | ignore errors and proceed with only the valid addresses. */ |
| is_smtp_blocking_err = (is_smtp_err && !data->set.mail_rcpt_allowfails); | |
| if(is_smtp_err) { | |
| @@ -57,14 +57,14 @@ static const uint8_t u8_smask[] = { | |
| * - We have an array: (id, string) are ideally placed at index "id % size". | |
| * - If slot at index is already occupied, we have a collision. | |
| * - A simple collision strategy would look at the next index, and the | |
| - | * next until until finding an empty slot. |
| + | * next until finding an empty slot. |
| * - The drawback is that this may lead to many checks on lookups, as it | |
| * will need to also look at subsequent slots until it finds the match. | |
| * The amount of lookups is the "probe sequence length" (psl) and this | |
| * may vary greatly between entries. | |
| * - Robin Hood Hashing balances the 'psl's of all entries more evenly: | |
| * - psl == 0 means an entry is in exactly the right slot | |
| - | * - pasl == 1 means it is in the slot right after. psl == 2 is the slot |
| + | * - psl == 1 means it is in the slot right after. psl == 2 is the slot |
| * after that, etc. | |
| * - when inserting a new entry, track its psl. Finding a slot where | |
| * the existing entry has a lower psl makes a swap. Put the new entry | |
| @@ -1699,7 +1699,7 @@ CURLUcode curl_url_get(const CURLU *u, CURLUPart what, | |
| ifmissing = CURLUE_NO_QUERY; | |
| plusdecode = flags & CURLU_URLDECODE; | |
| if(ptr && !ptr[0] && !(flags & CURLU_GET_EMPTY)) | |
| - | /* there was a blank query and the user do not ask for it */ |
| + | /* there was a blank query and the user does not ask for it */ |
| ptr = NULL; | |
| break; | |
| case CURLUPART_FRAGMENT: | |
| @@ -1157,8 +1157,8 @@ typedef void multi_sub_xfer_done_cb(struct Curl_easy *data, | |
| */ | |
| struct Curl_easy { | |
| - | /* First a simple identifier to easier detect if a user mix up this easy |
| - | handle with a multi handle. Set this to CURLEASY_MAGIC_NUMBER */ |
| + | /* First a simple identifier to more easily detect if a user mixes up this |
| + | easy handle with a multi handle. Set this to CURLEASY_MAGIC_NUMBER */ |
| uint32_t magic; | |
| /* once an easy handle is added to a multi, either explicitly by the | |
| * libcurl application or implicitly during `curl_easy_perform()`, | |
| @@ -179,7 +179,7 @@ static char *auth_digest_string_quoted(const char *s) | |
| } | |
| /* Retrieves the value for a corresponding key from the challenge string | |
| - | * returns TRUE if the key could be found, FALSE if it does not exists |
| + | * returns TRUE if the key could be found, FALSE if it does not exist |
| */ | |
| static bool auth_digest_get_key_value(const char *chlg, const char *key, | |
| char *buf, size_t buflen) | |
| @@ -3386,7 +3386,7 @@ static CURLcode ssh_connect(struct Curl_easy *data, bool *done) | |
| sock = conn->sock[FIRSTSOCKET]; | |
| #endif /* CURL_LIBSSH2_DEBUG */ | |
| - | /* libcurl MUST to set custom memory functions so that the kbd_callback |
| + | /* libcurl MUST set custom memory functions so that the kbd_callback |
| function's memory allocations can be properly freed */ | |
| sshc->ssh_session = libssh2_session_init_ex(my_libssh2_malloc, | |
| my_libssh2_free, | |
| @@ -1203,7 +1203,7 @@ static int engineload(struct Curl_easy *data, | |
| } | |
| if(!params.cert) { | |
| - | failf(data, "SSL engine did not initialized the certificate properly."); |
| + | failf(data, "SSL engine did not initialize the certificate properly."); |
| return 0; | |
| } | |
| @@ -1926,7 +1926,7 @@ static CURLcode ossl_shutdown(struct Curl_cfilter *cf, | |
| break; | |
| case SSL_ERROR_NONE: /* did not get anything */ | |
| case SSL_ERROR_WANT_READ: | |
| - | /* SSL has send its notify and now wants to read the reply |
| + | /* SSL has sent its notify and now wants to read the reply |
| * from the server. We are not really interested in that. */ | |
| CURL_TRC_CF(data, cf, "SSL shutdown sent, want receive"); | |
| connssl->io_need = CURL_SSL_IO_NEED_RECV; | |
| @@ -3773,7 +3773,7 @@ CURLcode Curl_ossl_ctx_init(struct ossl_ctx *octx, | |
| } | |
| /* OpenSSL contains code to work around lots of bugs and flaws in various | |
| - | SSL-implementations. SSL_CTX_set_options() is used to enabled those |
| + | SSL-implementations. SSL_CTX_set_options() is used to enable those |
| workarounds. The man page for this option states that SSL_OP_ALL enables | |
| all the workarounds and that "It is usually safe to use SSL_OP_ALL to | |
| enable the bug workaround options if compatibility with somewhat broken | |
| @@ -1418,7 +1418,7 @@ static CURLcode schannel_connect_step2(struct Curl_cfilter *cf, | |
| inbuf[1].cbBuffer)); | |
| /* There are two cases where we could be getting extra data here: | |
| 1. If we are renegotiating a connection and the handshake is already | |
| - | complete (from the server perspective), it can encrypted app data |
| + | complete (from the server perspective), it can encrypt app data |
| (not handshake data) in an extra buffer at this point. | |
| 2. (sspi_status == SEC_I_CONTINUE_NEEDED) We are negotiating a | |
| connection and this extra data is part of the handshake. | |
| @@ -1987,7 +1987,7 @@ static CURLcode wssl_shutdown(struct Curl_cfilter *cf, | |
| break; | |
| case WOLFSSL_ERROR_NONE: /* did not get anything */ | |
| case WOLFSSL_ERROR_WANT_READ: | |
| - | /* wolfSSL has send its notify and now wants to read the reply |
| + | /* wolfSSL has sent its notify and now wants to read the reply |
| * from the server. We are not really interested in that. */ | |
| CURL_TRC_CF(data, cf, "SSL shutdown sent, want receive"); | |
| connssl->io_need = CURL_SSL_IO_NEED_RECV; | |