Docs: Fix spelling and capitalization (#7408)
This commit is contained in:
parent
37ac2744cc
commit
fc696d52b9
2
.github/CONTRIBUTING.md
vendored
2
.github/CONTRIBUTING.md
vendored
|
@ -28,7 +28,7 @@ If you discover a security vulnerability, we'd appreciate a non-public disclosur
|
||||||
* Please make sure to test your change before submitting the PR. See [HACKING](https://raw.githubusercontent.com/systemd/systemd/master/HACKING) for details how to do this.
|
* Please make sure to test your change before submitting the PR. See [HACKING](https://raw.githubusercontent.com/systemd/systemd/master/HACKING) for details how to do this.
|
||||||
* Make sure to run the test suite locally, before posting your PR. We use a CI system, meaning we don't even look at your PR, if the build and tests don't pass.
|
* Make sure to run the test suite locally, before posting your PR. We use a CI system, meaning we don't even look at your PR, if the build and tests don't pass.
|
||||||
* If you need to update the code in an existing PR, force-push into the same branch, overriding old commits with new versions.
|
* If you need to update the code in an existing PR, force-push into the same branch, overriding old commits with new versions.
|
||||||
* After you have pushed a new version, add a comment about the new version (no notification is sent just for the commits, so it's easy to miss the update without an explicit comment). If you are a member of the systemd project on github, remove the `reviewed/needs-rework` label.
|
* After you have pushed a new version, add a comment about the new version (no notification is sent just for the commits, so it's easy to miss the update without an explicit comment). If you are a member of the systemd project on GitHub, remove the `reviewed/needs-rework` label.
|
||||||
|
|
||||||
## Final Words
|
## Final Words
|
||||||
|
|
||||||
|
|
10
CODING_STYLE
10
CODING_STYLE
|
@ -218,7 +218,7 @@
|
||||||
- We never use the POSIX version of basename() (which glibc defines it in
|
- We never use the POSIX version of basename() (which glibc defines it in
|
||||||
libgen.h), only the GNU version (which glibc defines in string.h).
|
libgen.h), only the GNU version (which glibc defines in string.h).
|
||||||
The only reason to include libgen.h is because dirname()
|
The only reason to include libgen.h is because dirname()
|
||||||
is needed. Everytime you need that please immediately undefine
|
is needed. Every time you need that please immediately undefine
|
||||||
basename(), and add a comment about it, so that no code ever ends up
|
basename(), and add a comment about it, so that no code ever ends up
|
||||||
using the POSIX version!
|
using the POSIX version!
|
||||||
|
|
||||||
|
@ -363,7 +363,7 @@
|
||||||
global variables. Why are global variables bad? They usually hinder
|
global variables. Why are global variables bad? They usually hinder
|
||||||
generic reusability of code (since they break in threaded programs,
|
generic reusability of code (since they break in threaded programs,
|
||||||
and usually would require locking there), and as the code using them
|
and usually would require locking there), and as the code using them
|
||||||
has side-effects make programs intransparent. That said, there are
|
has side-effects make programs non-transparent. That said, there are
|
||||||
many cases where they explicitly make a lot of sense, and are OK to
|
many cases where they explicitly make a lot of sense, and are OK to
|
||||||
use. For example, the log level and target in log.c is stored in a
|
use. For example, the log level and target in log.c is stored in a
|
||||||
global variable, and that's OK and probably expected by most. Also
|
global variable, and that's OK and probably expected by most. Also
|
||||||
|
@ -385,7 +385,7 @@
|
||||||
|
|
||||||
- When exposing public C APIs, be careful what function parameters you make
|
- When exposing public C APIs, be careful what function parameters you make
|
||||||
"const". For example, a parameter taking a context object should probably not
|
"const". For example, a parameter taking a context object should probably not
|
||||||
be "const", even if you are writing an other-wise read-only accessor function
|
be "const", even if you are writing an otherwise read-only accessor function
|
||||||
for it. The reason is that making it "const" fixates the contract that your
|
for it. The reason is that making it "const" fixates the contract that your
|
||||||
call won't alter the object ever, as part of the API. However, that's often
|
call won't alter the object ever, as part of the API. However, that's often
|
||||||
quite a promise, given that this even prohibits object-internal caching or
|
quite a promise, given that this even prohibits object-internal caching or
|
||||||
|
@ -395,14 +395,14 @@
|
||||||
|
|
||||||
- Make sure to enforce limits on every user controllable resource. If the user
|
- Make sure to enforce limits on every user controllable resource. If the user
|
||||||
can allocate resources in your code, your code must enforce some form of
|
can allocate resources in your code, your code must enforce some form of
|
||||||
limits after which it will refuse operation. It's fine if it is hardcoded (at
|
limits after which it will refuse operation. It's fine if it is hard-coded (at
|
||||||
least initially), but it needs to be there. This is particularly important
|
least initially), but it needs to be there. This is particularly important
|
||||||
for objects that unprivileged users may allocate, but also matters for
|
for objects that unprivileged users may allocate, but also matters for
|
||||||
everything else any user may allocated.
|
everything else any user may allocated.
|
||||||
|
|
||||||
- htonl()/ntohl() and htons()/ntohs() are weird. Please use htobe32() and
|
- htonl()/ntohl() and htons()/ntohs() are weird. Please use htobe32() and
|
||||||
htobe16() instead, it's much more descriptive, and actually says what really
|
htobe16() instead, it's much more descriptive, and actually says what really
|
||||||
is happening, after all htonl() and htons() don't operation on longs and
|
is happening, after all htonl() and htons() don't operate on longs and
|
||||||
shorts as their name would suggest, but on uint32_t and uint16_t. Also,
|
shorts as their name would suggest, but on uint32_t and uint16_t. Also,
|
||||||
"network byte order" is just a weird name for "big endian", hence we might
|
"network byte order" is just a weird name for "big endian", hence we might
|
||||||
want to call it "big endian" right-away.
|
want to call it "big endian" right-away.
|
||||||
|
|
Loading…
Reference in a new issue