fix first set of broken links

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

View file

@ -85,11 +85,11 @@ Use the indicated replacements for the functions below.
* `putenv` ⟶ * `putenv` ⟶
explicit `envp` argument in process creation 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` ⟶ * `setenv` ⟶
explicit `envp` argument in process creation 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` ⟶ * `strdupa` ⟶
`strdup` and `free` `strdup` and `free`
@ -102,11 +102,11 @@ explicit `envp` argument in process creation
* `system` ⟶ * `system` ⟶
`posix_spawn` `posix_spawn`
or `fork`pass:attributes[{blank}]/pass:attributes[{blank}]`execve`pass:attributes[{blank}]/ 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` ⟶ * `unsetenv` ⟶
explicit `envp` argument in process creation 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]] [[sect-Defensive_Coding-C-String-Functions-Length]]
=== String Functions with Explicit Length Arguments === String Functions with Explicit Length Arguments

View file

@ -5,7 +5,7 @@
== The Core Language == The Core Language
C++ includes a large subset of the C language. As far as the C 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[]` === 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 which allocates arrays with a variable length must check for
overflow manually. For the `new T[n]` example, overflow manually. For the `new T[n]` example,
the size check could be `n || (n > 0 && n > 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 additional dimensions (which must be constants according to the
{cpp} standard), these should be included as factors in the {cpp} standard), these should be included as factors in the
divisor. divisor.
These countermeasures prevent out-of-bounds writes and potential These countermeasures prevent out-of-bounds writes and potential
code execution. Very large memory allocations can still lead to 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 contains suggestions for mitigating this problem when processing
untrusted data. 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. for array allocation advice for C-style memory allocation.
=== Overloading === Overloading

View file

@ -5,7 +5,7 @@
== The C++ Standard Library == The C++ Standard Library
The C++ standard library includes most of its C counterpart 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]] [[sect-Defensive_Coding-CXX-Std-Functions]]
=== Functions That Are Difficult to Use === Functions That Are Difficult to Use

View file

@ -11,21 +11,21 @@ interpreter or standard library itself.
Other sections with Python-specific advice include: 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 * xref:../tasks/Tasks-Serialization.adoc#chap-Defensive_Coding-Tasks-Serialization[Serialization and Deserialization], in
particular <<sect-Defensive_Coding-Tasks-Serialization-Library>> 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 == Dangerous Standard Library Features
Some areas of the standard library, notably the Some areas of the standard library, notably the
`ctypes` module, do not provide memory safety `ctypes` module, do not provide memory safety
guarantees comparable to the rest of Python. If such 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 == Run-time Compilation and Code Generation

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 Vala is compiled to C, and the C code is compiled with GCC using
typical compiler flags. Basic operations like integer arithmetic typical compiler flags. Basic operations like integer arithmetic
are directly mapped to C constructs. As a results, the 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 In particular, the following Vala language constructs can result in
undefined behavior at run time: 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 * Pointer arithmetic, string subscripting and the
`substring` method on strings (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 arguments being passed are valid. This applies even to cases
(like `substring`) where the implementation (like `substring`) where the implementation
would have range information to check the validity of indexes. 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 * Similarly, Vala only performs garbage collection (through
reference counting) for `GObject` values. For reference counting) for `GObject` values. For
plain C pointers (such as strings), the programmer has to ensure plain C pointers (such as strings), the programmer has to ensure
that storage is deallocated once it is no longer needed (to that storage is deallocated once it is no longer needed (to
avoid memory leaks), and that storage is not being deallocated 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]).