Docs/defensive-coding-guide
2
0
Fork 0
Code Issues 3 Pull requests 1 Projects Releases Packages Wiki Activity Actions

fix first set of broken links

Browse source
This commit is contained in:
Huzaifa Sidhpurwala 2021-09-21 09:07:13 +05:30
parent 0ae85f9459
commit ced01f0bea
6 changed files with 19 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

BIN
modules/ROOT/pages/programming-languages/.CXX-Language.adoc.swp
View file

Binary file not shown.

8
modules/ROOT/pages/programming-languages/C-Libc.adoc
View file

@ -85,11 +85,11 @@ Use the indicated replacements for the functions below.
* `putenv` ⟶
explicit `envp` argument in process creation
(see <<sect-Defensive_Coding-Tasks-Processes-environ>>)
(see xref:../tasks/Tasks-Processes.adoc#sect-Defensive_Coding-Tasks-Processes-environ[Specifying the Process Environment])
* `setenv` ⟶
explicit `envp` argument in process creation
(see <<sect-Defensive_Coding-Tasks-Processes-environ>>)
(see xref:../tasks/Tasks-Processes.adoc#sect-Defensive_Coding-Tasks-Processes-environ[Specifying the Process Environment])
* `strdupa` ⟶
`strdup` and `free`
@ -102,11 +102,11 @@ explicit `envp` argument in process creation
* `system` ⟶
`posix_spawn`
or `fork`pass:attributes[{blank}]/pass:attributes[{blank}]`execve`pass:attributes[{blank}]/
(see <<sect-Defensive_Coding-Tasks-Processes-execve>>)
(see xref:../tasks/Tasks-Processes.adoc#sect-Defensive_Coding-Tasks-Processes-execve[Bypassing the Shell])
* `unsetenv` ⟶
explicit `envp` argument in process creation
(see <<sect-Defensive_Coding-Tasks-Processes-environ>>)
(see xref:../tasks/Tasks-Processes.adoc#sect-Defensive_Coding-Tasks-Processes-environ[Specifying the Process Environment])
[[sect-Defensive_Coding-C-String-Functions-Length]]
=== String Functions with Explicit Length Arguments

8
modules/ROOT/pages/programming-languages/CXX-Language.adoc
View file

@ -5,7 +5,7 @@
== The Core Language
C++ includes a large subset of the C language. As far as the C
subset is used, the recommendations in <<chap-Defensive_Coding-C>> apply.
subset is used, the recommendations in xref:../programming-languages/C.adoc#chap-Defensive_Coding-C[Defensive Coding in C] apply.
=== Array Allocation with `operator new[]`
@ -29,18 +29,18 @@ and the sources will be compiled with older GCC versions, code
which allocates arrays with a variable length must check for
overflow manually. For the `new T[n]` example,
the size check could be `n || (n > 0 && n >
(size_t(-1) - 8) / sizeof(T))`. (See <<sect-Defensive_Coding-C-Arithmetic>>.) If there are
(size_t(-1) - 8) / sizeof(T))`. (See xref:../programming-languages/C-Language.adoc#sect-Defensive_Coding-C-Arithmetic[Recommendations for Integer Arithmetic]) If there are
additional dimensions (which must be constants according to the
{cpp} standard), these should be included as factors in the
divisor.
These countermeasures prevent out-of-bounds writes and potential
code execution. Very large memory allocations can still lead to
a denial of service. <<sect-Defensive_Coding-Tasks-Serialization-Decoders>>
a denial of service. xref:../tasks/Tasks-Serialization.adoc#sect-Defensive_Coding-Tasks-Serialization-Decoders[Recommendations for Manually-written Decoders]
contains suggestions for mitigating this problem when processing
untrusted data.
See <<sect-Defensive_Coding-C-Allocators-Arrays>>
See xref:../tasks/programming-languages/C-Allocators.adoc#sect-Defensive_Coding-C-Allocators-Arrays[Array Allocation]
for array allocation advice for C-style memory allocation.
=== Overloading

2
modules/ROOT/pages/programming-languages/CXX-Std.adoc
View file

@ -5,7 +5,7 @@
== The C++ Standard Library
The C++ standard library includes most of its C counterpart
by reference, see <<sect-Defensive_Coding-C-Libc>>.
by reference, see xref:../programming-languages/C.adoc#chap-Defensive_Coding-C[Defensive Coding in C.
[[sect-Defensive_Coding-CXX-Std-Functions]]
=== Functions That Are Difficult to Use

12
modules/ROOT/pages/programming-languages/Python.adoc
View file

@ -11,21 +11,21 @@ interpreter or standard library itself.
Other sections with Python-specific advice include:
* <<chap-Defensive_Coding-Tasks-Temporary_Files>>
* xref:../tasks/Tasks-Temporary_Files.adoc#chap-Defensive_Coding-Tasks-Temporary_Files[Dealing with temp files]
* <<sect-Defensive_Coding-Tasks-Processes-Creation>>
* xref:../tasks/Tasks-Processes.adoc#sect-Defensive_Coding-Tasks-Processes-Creation[Creating Safe Processes]
* <<chap-Defensive_Coding-Tasks-Serialization>>, in
particular <<sect-Defensive_Coding-Tasks-Serialization-Library>>
* xref:../tasks/Tasks-Serialization.adoc#chap-Defensive_Coding-Tasks-Serialization[Serialization and Deserialization], in
particular xref:../tasks/Tasks-Serialization.adoc#sect-Defensive_Coding-Tasks-Serialization-Library[Library Support for Deserialization]
* <<sect-Defensive_Coding-Tasks-Cryptography-Randomness>>
* xref:../tasks/Tasks-Cryptography.adoc#sect-Defensive_Coding-Tasks-Cryptography-Randomness[Randomness]
== Dangerous Standard Library Features
Some areas of the standard library, notably the
`ctypes` module, do not provide memory safety
guarantees comparable to the rest of Python. If such
functionality is used, the advice in <<sect-Defensive_Coding-C-Language>> should be followed.
functionality is used, the advice in xref:../programming-languages/C.adoc#chap-Defensive_Coding-C[Defensive Coding in C] should be followed.
== Run-time Compilation and Code Generation

8
modules/ROOT/pages/programming-languages/Vala.adoc
View file

@ -11,12 +11,12 @@ unlike C# and Java, Vala does not attempt to provide memory safety:
Vala is compiled to C, and the C code is compiled with GCC using
typical compiler flags. Basic operations like integer arithmetic
are directly mapped to C constructs. As a results, the
recommendations in <<chap-Defensive_Coding-C>> apply.
recommendations in xref:../programming-languages/C.adoc#chap-Defensive_Coding-C[Defensive Coding in C] apply.
In particular, the following Vala language constructs can result in
undefined behavior at run time:
* Integer arithmetic, as described in <<sect-Defensive_Coding-C-Arithmetic>>.
* Integer arithmetic, as described in xref:../programming-languages/C-Language.adoc#sect-Defensive_Coding-C-Arithmetic[Recommendations for Integer Arithmetic].
* Pointer arithmetic, string subscripting and the
`substring` method on strings (the
@ -26,11 +26,11 @@ is the responsibility of the calling code to ensure that the
arguments being passed are valid. This applies even to cases
(like `substring`) where the implementation
would have range information to check the validity of indexes.
See <<sect-Defensive_Coding-C-Pointers>>.
See xref:../programming-languages/C-Language.adoc#sect-Defensive_Coding-C-Pointers[Recommendations for Pointers and Array Handling]
* Similarly, Vala only performs garbage collection (through
reference counting) for `GObject` values. For
plain C pointers (such as strings), the programmer has to ensure
that storage is deallocated once it is no longer needed (to
avoid memory leaks), and that storage is not being deallocated
while it is still being used (see <<sect-Defensive_Coding-C-Use-After-Free>>).
while it is still being used (see xref:../programming-languages/C-Allocators.adoc#sect-Defensive_Coding-C-Use-After-Free[Use-after-free errors]).