mirror of
https://github.com/curl/curl.git
synced 2025-04-18 16:30:45 +08:00
docs: correct spelling errors and a broken link
Update grammar and spelling in docs and source code comments. Closes: #7427 Reviewed-by: Daniel Stenberg <daniel@haxx.se>
This commit is contained in:
parent
2c2b26145f
commit
8749ce651f
@ -56,7 +56,7 @@ CURLcode Curl_bufref_memdup(struct bufref *br, const void *data, size_t length);
|
||||
```
|
||||
|
||||
Releases the previously referenced buffer, then duplicates the `length`-byte
|
||||
`data` into a buffer allocated via `malloc()` and references the later
|
||||
`data` into a buffer allocated via `malloc()` and references the latter
|
||||
associated with destructor `curl_free()`.
|
||||
|
||||
An additional trailing byte is allocated and set to zero as a possible
|
||||
|
@ -34,7 +34,7 @@
|
||||
HackerOne](https://hackerone.com/curl).
|
||||
|
||||
This ensures that the report reaches the curl security team so that they
|
||||
first can be deal with the report away from the public to minimize the harm
|
||||
first can deal with the report away from the public to minimize the harm
|
||||
and impact it will have on existing users out there who might be using the
|
||||
vulnerable versions.
|
||||
|
||||
@ -67,7 +67,7 @@
|
||||
|
||||
If curl crashed, causing a core dump (in unix), there is hardly any use to
|
||||
send that huge file to anyone of us. Unless we have an exact same system
|
||||
setup as you, we can't do much with it. Instead we ask you to get a stack
|
||||
setup as you, we can't do much with it. Instead, we ask you to get a stack
|
||||
trace and send that (much smaller) output to us instead!
|
||||
|
||||
The address and how to subscribe to the mailing lists are detailed in the
|
||||
@ -168,7 +168,7 @@
|
||||
experiencing.
|
||||
|
||||
Security wise, it is almost always a bad idea to lag behind the current curl
|
||||
versions by a lot. We keeping discovering and reporting security problems
|
||||
versions by a lot. We keep discovering and reporting security problems
|
||||
over time see you can see in [this
|
||||
table](https://curl.se/docs/vulnerabilities.html)
|
||||
|
||||
|
@ -19,7 +19,7 @@ alerts.
|
||||
## How to provide feedback to author
|
||||
|
||||
Be nice. Ask questions. Provide examples or suggestions of improvements.
|
||||
Assume best intentions. Remember language barriers.
|
||||
Assume the best intentions. Remember language barriers.
|
||||
|
||||
All first-time contributors can become regulars. Let's help them go there.
|
||||
|
||||
@ -43,7 +43,7 @@ intact as far as possible.
|
||||
## Code style
|
||||
|
||||
Most code style nits are detected by checksrc but not all. Only leave remarks
|
||||
on style deviation once checksrc doesn't find any more.
|
||||
on style deviation once checksrc doesn't find anymore.
|
||||
|
||||
Minor nits from fresh submitters can also be handled by the maintainer when
|
||||
merging, in case it seems like the submitter isn't clear on what to do. We
|
||||
@ -100,7 +100,7 @@ test individual functions.
|
||||
|
||||
## Documentation
|
||||
|
||||
New features or changes to existing functionality **must** be accompanied with
|
||||
New features or changes to existing functionality **must** be accompanied by
|
||||
updated documentation. Submitting that in a separate follow-up pull request is
|
||||
not OK. A code review must also verify that the submitted documentation update
|
||||
matches the code submission.
|
||||
|
@ -151,7 +151,7 @@ changes merged.
|
||||
|
||||
We strongly prefer pull requests to mailed patches, as it makes it a proper
|
||||
git commit that is easy to merge and they are easy to track and not that easy
|
||||
to loose in the flood of many emails, like they sometimes do on the mailing
|
||||
to lose in the flood of many emails, like they sometimes do on the mailing
|
||||
lists.
|
||||
|
||||
Every pull request submitted will automatically be tested in several different
|
||||
|
@ -3,7 +3,7 @@
|
||||
If any of these deprecated features is a cause for concern for you, please
|
||||
email the curl-library mailing list as soon as possible and explain to us why
|
||||
this is a problem for you and how your use case can't be satisfied properly
|
||||
using a work around.
|
||||
using a workaround.
|
||||
|
||||
## Past removals
|
||||
|
||||
|
@ -55,7 +55,7 @@ The following set of resources is currently known to be available.
|
||||
|
||||
### PR 4011 (Jun 2019) expected in curl release 7.67.0 (Oct 2019)
|
||||
|
||||
- Details [below](#pr4011);
|
||||
- Details [below](#pr-4011);
|
||||
|
||||
- New configuration option: `--enable-ech`;
|
||||
|
||||
|
@ -11,7 +11,7 @@ ABI - Application Binary Interface
|
||||
|
||||
A libcurl upgrade does not break the ABI or change established and documented
|
||||
behavior. Your application can remain using libcurl just as before, only with
|
||||
less bugs and possibly with added new features.
|
||||
fewer bugs and possibly with added new features.
|
||||
|
||||
## Version Numbers
|
||||
|
||||
|
@ -279,7 +279,7 @@ static CURLcode pre_transfer(struct GlobalConfig *global,
|
||||
*
|
||||
* - Stat gives a size but this is UNRELIABLE in VMS As a f.e. a
|
||||
* fixed file with implied CC needs to have a byte added for every
|
||||
* record processed, this can by derived from Filesize & recordsize
|
||||
* record processed, this can be derived from Filesize & recordsize
|
||||
* for VARiable record files the records need to be counted! for
|
||||
* every record add 1 for linefeed and subtract 2 for the record
|
||||
* header for VARIABLE header files only the bare record data needs
|
||||
@ -530,7 +530,7 @@ static CURLcode post_per_transfer(struct GlobalConfig *global,
|
||||
}
|
||||
if(outs->bytes && outs->filename && outs->stream) {
|
||||
int rc;
|
||||
/* We have written data to a output file, we truncate file
|
||||
/* We have written data to an output file, we truncate file
|
||||
*/
|
||||
if(!global->mute)
|
||||
fprintf(global->errors, "Throwing away %"
|
||||
@ -1181,7 +1181,7 @@ static CURLcode single_transfer(struct GlobalConfig *global,
|
||||
input->config = config;
|
||||
/* Note that if CURLOPT_READFUNCTION is fread (the default), then
|
||||
* lib/telnet.c will Curl_poll() on the input file descriptor
|
||||
* rather then calling the READFUNCTION at regular intervals.
|
||||
* rather than calling the READFUNCTION at regular intervals.
|
||||
* The circumstances in which it is preferable to enable this
|
||||
* behavior, by omitting to set the READFUNCTION & READDATA options,
|
||||
* have not been determined.
|
||||
@ -1483,7 +1483,7 @@ static CURLcode single_transfer(struct GlobalConfig *global,
|
||||
|
||||
/* In debug build of curl tool, using
|
||||
* --cert loadmem=<filename>:<password> --cert-type p12
|
||||
* must do the same thing than classic:
|
||||
* must do the same thing as classic:
|
||||
* --cert <filename>:<password> --cert-type p12
|
||||
* but is designed to test blob */
|
||||
#if defined(CURLDEBUG) || defined(DEBUGBUILD)
|
||||
@ -2048,7 +2048,7 @@ static CURLcode single_transfer(struct GlobalConfig *global,
|
||||
}
|
||||
else {
|
||||
/* Free this URL node data without destroying the
|
||||
the node itself nor modifying next pointer. */
|
||||
node itself nor modifying next pointer. */
|
||||
Curl_safefree(urlnode->outfile);
|
||||
Curl_safefree(urlnode->infile);
|
||||
urlnode->flags = 0;
|
||||
|
Loading…
x
Reference in New Issue
Block a user