defensive-coding-guide/defensive-coding/pot/C/Language.pot

135 lines
5.7 KiB
Text
Raw Normal View History

2013-03-11 23:20:11 -04:00
#
# AUTHOR <EMAIL@ADDRESS>, YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: 0\n"
"POT-Creation-Date: 2013-03-12T03:19:44\n"
"PO-Revision-Date: 2013-03-12T03:19:44\n"
"Last-Translator: Automatically generated\n"
"Language-Team: None\n"
"MIME-Version: 1.0\n"
"Content-Type: application/x-publican; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#. Tag: title
#, no-c-format
msgid "The core language"
msgstr ""
#. Tag: para
#, no-c-format
msgid "C provides no memory safety. Most recommendations in this section deal with this aspect of the language."
msgstr ""
#. Tag: title
#, no-c-format
msgid "Undefined behavior"
msgstr ""
#. Tag: para
#, no-c-format
msgid "Some C constructs are defined to be undefined by the C standard. This does not only mean that the standard does not describe what happens when the construct is executed. It also allows optimizing compilers such as GCC to assume that this particular construct is never reached. In some cases, this has caused GCC to optimize security checks away. (This is not a flaw in GCC or the C language. But C certainly has some areas which are more difficult to use than others.)"
msgstr ""
#. Tag: para
#, no-c-format
msgid "Common sources of undefined behavior are:"
msgstr ""
#. Tag: para
#, no-c-format
msgid "out-of-bounds array accesses"
msgstr ""
#. Tag: para
#, no-c-format
msgid "null pointer dereferences"
msgstr ""
#. Tag: para
#, no-c-format
msgid "overflow in signed integer arithmetic"
msgstr ""
#. Tag: title
#, no-c-format
msgid "Recommendations for pointers and array handling"
msgstr ""
#. Tag: para
#, no-c-format
msgid "Always keep track of the size of the array you are working with. Often, code is more obviously correct when you keep a pointer past the last element of the array, and calculate the number of remaining elements by substracting the current position from that pointer. The alternative, updating a separate variable every time when the position is advanced, is usually less obviously correct."
msgstr ""
#. Tag: para
#, no-c-format
msgid "<xref linkend=\"ex-Defensive_Coding-C-Pointers-remaining\" /> shows how to extract Pascal-style strings from a character buffer. The two pointers kept for length checks are <varname>inend</varname> and <varname>outend</varname>. <varname>inp</varname> and <varname>outp</varname> are the respective positions. The number of input bytes is checked using the expression <literal>len &gt; (size_t)(inend - inp)</literal>. The cast silences a compiler warning; <varname>inend</varname> is always larger than <varname>inp</varname>."
msgstr ""
#. Tag: title
#, no-c-format
msgid "Array processing in C"
msgstr ""
#. Tag: para
#, no-c-format
msgid "It is important that the length checks always have the form <literal>len &gt; (size_t)(inend - inp)</literal>, where <varname>len</varname> is a variable of type <type>size_t</type> which denotes the <emphasis>total</emphasis> number of bytes which are about to be read or written next. In general, it is not safe to fold multiple such checks into one, as in <literal>len1 + len2 &gt; (size_t)(inend - inp)</literal>, because the expression on the left can overflow or wrap around (see <xref linkend=\"sect-Defensive_Coding-C-Arithmetic\" />), and it no longer reflects the number of bytes to be processed."
msgstr ""
#. Tag: title
#, no-c-format
msgid "Recommendations for integer arithmetic"
msgstr ""
#. Tag: para
#, no-c-format
msgid "Overflow in signed integer arithmetic is undefined. This means that it is not possible to check for overflow after it happened, see <xref linkend=\"ex-Defensive_Coding-C-Arithmetic-bad\" />."
msgstr ""
#. Tag: title
#, no-c-format
msgid "Incorrect overflow detection in C"
msgstr ""
#. Tag: para
#, no-c-format
msgid "The following approaches can be used to check for overflow, without actually causing it."
msgstr ""
#. Tag: para
#, no-c-format
msgid "Use a wider type to perform the calculation, check that the result is within bounds, and convert the result to the original type. All intermediate results must be checked in this way."
msgstr ""
#. Tag: para
#, no-c-format
msgid "Perform the calculation in the corresponding unsigned type and use bit fiddling to detect the overflow."
msgstr ""
#. Tag: para
#, no-c-format
msgid "Compute bounds for acceptable input values which are known to avoid overflow, and reject other values. This is the preferred way for overflow checking on multiplications, see <xref linkend=\"ex-Defensive_Coding-C-Arithmetic-mult\" />."
msgstr ""
#. Tag: title
#, no-c-format
msgid "Overflow checking for unsigned multiplication"
msgstr ""
#. Tag: para
#, no-c-format
msgid "Basic arithmetic operations a commutative, so for bounds checks, there are two different but mathematically equivalent expressions. Sometimes, one of the expressions results in better code because parts of it can be reduced to a constant. This applies to overflow checks for multiplication <literal>a * b</literal> involving a constant <literal>a</literal>, where the expression is reduced to <literal>b &gt; C</literal> for some constant <literal>C</literal> determined at compile time. The other expression, <literal>b &amp;&amp; a &gt; ((unsigned)-1) / b</literal>, is more difficult to optimize at compile time."
msgstr ""
#. Tag: para
#, no-c-format
msgid "When a value is converted to a signed integer, GCC always chooses the result based on 2's complement arithmetic. This GCC extension (which is also implemented by other compilers) helps a lot when implementing overflow checks."
msgstr ""
#. Tag: para
#, no-c-format
msgid "Legacy code should be compiled with the <option>-fwrapv</option> GCC option. As a result, GCC will provide 2's complement semantics for integer arithmetic, including defined behavior on integer overflow."
msgstr ""