[defensive-coding-guide] 110/120: Go: Add section on deserialization
by git repository hosting
This is an automated email from the git hooks/post-receive script.
sparks pushed a commit to branch master
in repository defensive-coding-guide.
commit 18654176d5d06211ba6393ceaf83afc53080d146
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Wed Aug 13 09:44:05 2014 +0200
Go: Add section on deserialization
In particular, warn about information leakage due to object reuse.
---
defensive-coding/en-US/Go.xml | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/defensive-coding/en-US/Go.xml b/defensive-coding/en-US/Go.xml
index 0e44d5e..b5529a6 100644
--- a/defensive-coding/en-US/Go.xml
+++ b/defensive-coding/en-US/Go.xml
@@ -87,4 +87,24 @@
spontaneously.
</para>
</section>
+<section id="chap-Defensive_Coding-Go-Marshaling">
+ <title>Marshaling and marshaling</title>
+ <para>
+ Several packages in the <literal>encoding</literal> hierarchy
+ provide support for serialization and deserialization. The usual
+ caveats apply (see
+ <xref linkend="chap-Defensive_Coding-Tasks-Serialization"/>).
+ </para>
+ <para>
+ As an additional precaution, the <function>Unmarshal</function>
+ and <function>Decode</function> functions should only be used with
+ fresh values in the <literal>interface{}</literal> argument. This
+ is due to the way defaults for missing values are implemented:
+ During deserialization, missing value do not result in an error,
+ but the original value is preserved. Using a fresh value (with
+ suitable default values if necessary) ensures that data from a
+ previous deserialization operation does not leak into the current
+ one. This is especially relevant when structs are deserialized.
+ </para>
+</section>
</chapter>
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 109/120: Update revision history in
preparation of publication
by git repository hosting
This is an automated email from the git hooks/post-receive script.
sparks pushed a commit to branch master
in repository defensive-coding-guide.
commit 5bf22d94092bb89c90855b46a62fba3f58d2b46d
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Wed Jul 16 17:30:47 2014 +0200
Update revision history in preparation of publication
---
defensive-coding/en-US/Revision_History.xml | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/defensive-coding/en-US/Revision_History.xml b/defensive-coding/en-US/Revision_History.xml
index fc79226..f0f0c78 100644
--- a/defensive-coding/en-US/Revision_History.xml
+++ b/defensive-coding/en-US/Revision_History.xml
@@ -8,6 +8,28 @@
<simpara>
<revhistory>
<revision>
+ <revnumber>1.2-1</revnumber>
+ <date>Wed Jul 16 2014</date>
+ <author>
+ <firstname>Florian</firstname>
+ <surname>Weimer</surname>
+ <email>fweimer(a)redhat.com</email>
+ </author>
+ <revdescription>
+ <simplelist>
+ <member>C: Corrected the <function>strncat</function> example</member>
+ <member>C: Mention mixed signed/unsigned comparisons</member>
+ <member>C: Unsigned overflow checking example</member>
+ <member>C++: <literal>operator new[]</literal> has been fixed in GCC</member>
+ <member>C++: Additional material on <literal>std::string</literal>, iterators</member>
+ <member>OpenSSL: Mention <command>openssl genrsa</command> entropy issue</member>
+ <member>Packaging: X.509 key generation</member>
+ <member>Go, Vala: Add short chapters</member>
+ <member>Serialization: Notes on fragmentation and reassembly</member>
+ </simplelist>
+ </revdescription>
+ </revision>
+ <revision>
<revnumber>1.1-1</revnumber>
<date>Tue Aug 27 2013</date>
<author>
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 108/120: Update the copyright date
by git repository hosting
This is an automated email from the git hooks/post-receive script.
sparks pushed a commit to branch master
in repository defensive-coding-guide.
commit e2bab310553e9c62e5fff9660988f4aa090f63d5
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Wed Jul 16 17:24:08 2014 +0200
Update the copyright date
---
defensive-coding/en-US/Defensive_Coding.ent | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/defensive-coding/en-US/Defensive_Coding.ent b/defensive-coding/en-US/Defensive_Coding.ent
index ae4cb86..e7b7e9f 100644
--- a/defensive-coding/en-US/Defensive_Coding.ent
+++ b/defensive-coding/en-US/Defensive_Coding.ent
@@ -1,2 +1,2 @@
-<!ENTITY YEAR "2012-2013">
+<!ENTITY YEAR "2012-2014">
<!ENTITY HOLDER "Red Hat, Inc">
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 105/120: C: Add example for unsigned
overflow check
by git repository hosting
This is an automated email from the git hooks/post-receive script.
sparks pushed a commit to branch master
in repository defensive-coding-guide.
commit e97e4dc0e06ef037b2042a251c17e1f4a66ccc66
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Fri Jun 6 16:49:27 2014 +0200
C: Add example for unsigned overflow check
---
defensive-coding/en-US/C-Language.xml | 11 +++++++++++
.../en-US/snippets/C-Arithmetic-add_unsigned.xml | 17 +++++++++++++++++
defensive-coding/src/C-Arithmetic-add.c | 14 ++++++++++++++
3 files changed, 42 insertions(+)
diff --git a/defensive-coding/en-US/C-Language.xml b/defensive-coding/en-US/C-Language.xml
index b1eeec0..8f6f74d 100644
--- a/defensive-coding/en-US/C-Language.xml
+++ b/defensive-coding/en-US/C-Language.xml
@@ -103,8 +103,19 @@
<para>
Perform the calculation in the corresponding unsigned type
and use bit fiddling to detect the overflow.
+ <xref linkend="ex-Defensive_Coding-C-Arithmetic-add_unsigned"/>
+ shows how to perform an overflow check for unsigned integer
+ addition. For three or more terms, all the intermediate
+ additions have to be checked in this way.
</para>
</listitem>
+ </itemizedlist>
+ <example id="ex-Defensive_Coding-C-Arithmetic-add_unsigned">
+ <title>Overflow checking for unsigned addition</title>
+ <xi:include href="snippets/C-Arithmetic-add_unsigned.xml"
+ xmlns:xi="http://www.w3.org/2001/XInclude" />
+ </example>
+ <itemizedlist>
<listitem>
<para>
Compute bounds for acceptable input values which are known
diff --git a/defensive-coding/en-US/snippets/C-Arithmetic-add_unsigned.xml b/defensive-coding/en-US/snippets/C-Arithmetic-add_unsigned.xml
new file mode 100644
index 0000000..4ea1747
--- /dev/null
+++ b/defensive-coding/en-US/snippets/C-Arithmetic-add_unsigned.xml
@@ -0,0 +1,17 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE programlisting PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+<!-- Automatically generated file. Do not edit. -->
+<programlisting language="C">
+void report_overflow(void);
+
+unsigned
+add_unsigned(unsigned a, unsigned b)
+{
+ unsigned sum = a + b;
+ if (sum < a) { // or sum < b
+ report_overflow();
+ }
+ return sum;
+}
+</programlisting>
diff --git a/defensive-coding/src/C-Arithmetic-add.c b/defensive-coding/src/C-Arithmetic-add.c
index 3e70286..95b403e 100644
--- a/defensive-coding/src/C-Arithmetic-add.c
+++ b/defensive-coding/src/C-Arithmetic-add.c
@@ -15,3 +15,17 @@ add(int a, int b)
return result;
}
//-
+
+//+ C Arithmetic-add_unsigned
+void report_overflow(void);
+
+unsigned
+add_unsigned(unsigned a, unsigned b)
+{
+ unsigned sum = a + b;
+ if (sum < a) { // or sum < b
+ report_overflow();
+ }
+ return sum;
+}
+//-
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 104/120: Serialization: Add section on
fragmentation and reassembly
by git repository hosting
This is an automated email from the git hooks/post-receive script.
sparks pushed a commit to branch master
in repository defensive-coding-guide.
commit 01bd3904dc2a71c18727a4ddd7bd53f1bc56a929
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Fri Jun 6 15:03:32 2014 +0200
Serialization: Add section on fragmentation and reassembly
---
defensive-coding/en-US/Tasks-Serialization.xml | 130 +++++++++++++++++++++++++
1 file changed, 130 insertions(+)
diff --git a/defensive-coding/en-US/Tasks-Serialization.xml b/defensive-coding/en-US/Tasks-Serialization.xml
index 008e75b..81ba061 100644
--- a/defensive-coding/en-US/Tasks-Serialization.xml
+++ b/defensive-coding/en-US/Tasks-Serialization.xml
@@ -42,6 +42,136 @@
characters simplifies testing and debugging. However, binary
protocols with length fields may be more efficient to parse.
</para>
+ <para>
+ In new datagram-oriented protocols, unique numbers such as
+ sequence numbers or identifiers for fragment reassembly (see
+ <xref
+ linkend="sect-Defensive_Coding-Tasks-Serialization-Fragmentation"/>)
+ should be at least 64 bits large, and really should not be
+ smaller than 32 bits in size. Protocols should not permit
+ fragments with overlapping contents.
+ </para>
+ </section>
+
+ <section id="sect-Defensive_Coding-Tasks-Serialization-Fragmentation">
+ <title>Fragmentation</title>
+ <para>
+ Some serialization formats use frames or protocol data units
+ (PDUs) on lower levels which are smaller than the PDUs on higher
+ levels. With such an architecture, higher-level PDUs may have
+ to be <emphasis>fragmented</emphasis> into smaller frames during
+ serialization, and frames may need
+ <emphasis>reassembly</emphasis> into large PDUs during
+ deserialization.
+ </para>
+ <para>
+ Serialization formats may use conceptually similar structures
+ for completely different purposes, for example storing multiple
+ layers and color channels in a single image file.
+ </para>
+ <para>
+ When fragmenting PDUs, establish a reasonable lower bound for
+ the size of individual fragments (as large as possible—limits as
+ low as one or even zero can add substantial overhead). Avoid
+ fragmentation if at all possible, and try to obtain the maximum
+ acceptable fragment length from a trusted data source.
+ </para>
+ <para>
+ When implementing reassembly, consider the following aspects.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Avoid allocating significant amount of resources without
+ proper authentication. Allocate memory for the unfragmented
+ PDU as more and more and fragments are encountered, and not
+ based on the initially advertised unfragmented PDU size,
+ unless there is a sufficiently low limit on the unfragmented
+ PDU size, so that over-allocation cannot lead to performance
+ problems.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Reassembly queues on top of datagram-oriented transports
+ should be bounded, both in the combined size of the arrived
+ partial PDUs waiting for reassembly, and the total number of
+ partially reassembled fragments. The latter limit helps to
+ reduce the risk of accidental reassembly of unrelated
+ fragments, as it can happen with small fragment IDs (see
+ <xref linkend="sect-Defensive_Coding-Tasks-Serialization-Fragmentation-ID"/>).
+ It also guards to some extent against deliberate injection of fragments,
+ by guessing fragment IDs.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Carefully keep track of which bytes in the unfragmented PDU
+ have been covered by fragments so far. If message
+ reordering is a concern, the most straightforward data
+ structure for this is an array of bits, with one bit for
+ every byte (or other atomic unit) in the unfragmented PDU.
+ Complete reassembly can be determined by increasing a
+ counter of set bits in the bit array as the bit array is
+ updated, taking overlapping fragments into consideration.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Reject overlapping fragments (that is, multiple fragments
+ which provide data at the same offset of the PDU being
+ fragmented), unless the protocol explicitly requires
+ accepting overlapping fragments. The bit array used for
+ tracking already arrived bytes can be used for this purpose.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Check for conflicting values of unfragmented PDU lengths (if
+ this length information is part of every fragment) and
+ reject fragments which are inconsistent.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Validate fragment lengths and offsets of individual
+ fragments against the unfragmented PDU length (if they are
+ present). Check that the last byte in the fragment does not
+ lie after the end of the unfragmented PDU. Avoid integer
+ overflows in these computations (see <xref
+ linkend="sect-Defensive_Coding-C-Arithmetic"/>).
+ </para>
+ </listitem>
+ </itemizedlist>
+ <section id="sect-Defensive_Coding-Tasks-Serialization-Fragmentation-ID">
+ <title>Fragment IDs</title>
+ <para>
+ If the underlying transport is datagram-oriented (so that PDUs
+ can be reordered, duplicated or be lost, like with UDP),
+ fragment reassembly needs to take into account endpoint
+ addresses of the communication channel, and there has to be
+ some sort of fragment ID which identifies the individual
+ fragments as part of a larger PDU. In addition, the
+ fragmentation protocol will typically involve fragment offsets
+ and fragment lengths, as mentioned above.
+ </para>
+ <para>
+ If the transport may be subject to blind PDU injection (again,
+ like UDP), the fragment ID must be generated randomly. If the
+ fragment ID is 64 bit or larger (strongly recommended), it can
+ be generated in a completely random fashion for most traffic
+ volumes. If it is less than 64 bits large (so that accidental
+ collisions can happen if a lot of PDUs are transmitted), the
+ fragment ID should be incremented sequentially from a starting
+ value. The starting value should be derived using a HMAC-like
+ construction from the endpoint addresses, using a long-lived
+ random key. This construction ensures that despite the
+ limited range of the ID, accidental collisions are as unlikely
+ as possible. (This will not work reliable with really short
+ fragment IDs, such as the 16 bit IDs used by the Internet
+ Protocol.)
+ </para>
+ </section>
</section>
<section>
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 103/120: Packaging: Adjust RPM flags of
key-related files
by git repository hosting
This is an automated email from the git hooks/post-receive script.
sparks pushed a commit to branch master
in repository defensive-coding-guide.
commit f5803d1403f9adf1cb54dd5ab93bb649d5e07c88
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Fri Jun 6 13:32:50 2014 +0200
Packaging: Adjust RPM flags of key-related files
---
defensive-coding/en-US/Tasks-Packaging.xml | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/defensive-coding/en-US/Tasks-Packaging.xml b/defensive-coding/en-US/Tasks-Packaging.xml
index 5562f45..3e3feab 100644
--- a/defensive-coding/en-US/Tasks-Packaging.xml
+++ b/defensive-coding/en-US/Tasks-Packaging.xml
@@ -86,11 +86,20 @@ fi
%files
%dir %attr(0755,%{tlsuser},%{tlsuser]) %{tlsdir}
-%ghost %attr(0600,%{tlsuser},%{tlsuser}) %{tlskey}
-%ghost %attr(0644,%{tlsuser},%{tlsuser}) %{tlscert}
+%ghost %attr(0600,%{tlsuser},%{tlsuser}) %config(noreplace) %{tlskey}
+%ghost %attr(0644,%{tlsuser},%{tlsuser}) %config(noreplace) %{tlscert}
</programlisting>
</example>
<para>
+ The files containing the key material are marked as ghost
+ configuration files. This ensures that they are tracked in the
+ RPM database as associated with the package, but RPM will not
+ create them when the package is installed and not verify their
+ contents (the <literal>%ghost</literal>), or delete the files
+ when the package is uninstalled (the
+ <literal>%config(noreplace)</literal> part).
+ </para>
+ <para>
If the <emphasis>directory</emphasis>
<literal>%{tlsdir}</literal> <emphasis>is owned by</emphasis>
<literal>root</literal>, use the code in <xref
@@ -114,8 +123,8 @@ fi
%files
%dir %attr(0755,root,root]) %{tlsdir}
-%ghost %attr(0600,%{tlsuser},%{tlsuser}) %{tlskey}
-%ghost %attr(0644,root,root) %{tlscert}
+%ghost %attr(0600,%{tlsuser},%{tlsuser}) %config(noreplace) %{tlskey}
+%ghost %attr(0644,root,root) %config(noreplace) %{tlscert}
</programlisting>
</example>
<para>
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 102/120: Packaging: Fix RPM macro issue
by git repository hosting
This is an automated email from the git hooks/post-receive script.
sparks pushed a commit to branch master
in repository defensive-coding-guide.
commit 11ef1e626053e2562a03c90eee67acb8c93f26af
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Fri Jun 6 13:27:43 2014 +0200
Packaging: Fix RPM macro issue
---
defensive-coding/en-US/Tasks-Packaging.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/defensive-coding/en-US/Tasks-Packaging.xml b/defensive-coding/en-US/Tasks-Packaging.xml
index 07ee072..5562f45 100644
--- a/defensive-coding/en-US/Tasks-Packaging.xml
+++ b/defensive-coding/en-US/Tasks-Packaging.xml
@@ -113,9 +113,9 @@ if [ $1 -eq 1 ] ; then
fi
%files
-%dir %attr(0755,%{root},%{root}]) %{tlsdir}
+%dir %attr(0755,root,root]) %{tlsdir}
%ghost %attr(0600,%{tlsuser},%{tlsuser}) %{tlskey}
-%ghost %attr(0644,%{root},%{root}) %{tlscert}
+%ghost %attr(0644,root,root) %{tlscert}
</programlisting>
</example>
<para>
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 101/120: Packaging: Add section on delayed
certificate generation
by git repository hosting
This is an automated email from the git hooks/post-receive script.
sparks pushed a commit to branch master
in repository defensive-coding-guide.
commit dc0ff1a16e89bdd14cf0f157bacc40a15367702f
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Fri Jun 6 13:26:37 2014 +0200
Packaging: Add section on delayed certificate generation
---
defensive-coding/en-US/Tasks-Packaging.xml | 37 +++++++++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/defensive-coding/en-US/Tasks-Packaging.xml b/defensive-coding/en-US/Tasks-Packaging.xml
index 95bfbc6..07ee072 100644
--- a/defensive-coding/en-US/Tasks-Packaging.xml
+++ b/defensive-coding/en-US/Tasks-Packaging.xml
@@ -20,7 +20,8 @@
such use, generating the key pair at package installation time
when preparing system images for use in the cluster is
reasonable. For other use cases, it is necessary to generate
- the key pair before the service is started for the first time.
+ the key pair before the service is started for the first time,
+ see <xref linkend="sect-Defensive_Coding-Tasks-Packaging-Certificates-Service"/>.
</para>
<important>
<para>
@@ -128,4 +129,38 @@ fi
<application>chmod</application> invocation.
</para>
</section>
+ <section id="sect-Defensive_Coding-Tasks-Packaging-Certificates-Service">
+ <title>Generating X.509 self-signed certificates before service
+ start</title>
+ <para>
+ An alternative way to automatically provide an X.509 key pair is
+ to create it just before the service is started for the first
+ time. This ensures that installation images which are created
+ from installed RPM packages receive different key material.
+ Creating the key pair at package installation time (see <xref
+ linkend="sect-Defensive_Coding-Tasks-Packaging-Certificates"/>)
+ would put the key into the image, which may or may not make
+ sense.
+ </para>
+ <important>
+ <para>
+ The caveats about the way the key is generated in <xref
+ linkend="sect-Defensive_Coding-Tasks-Packaging-Certificates"/>
+ apply to this procedure as well.
+ </para>
+ </important>
+ <para>
+ Generating key material before service start may happen very
+ early during boot, when the kernel randomness pool has not yet
+ been initialized. Currently, the only way to check for the
+ initialization is to look for the kernel message
+ <literal>random: nonblocking pool is initialized</literal>. In
+ theory, it is also possible to read from
+ <filename>/dev/random</filename> while generating the key
+ material (instead of <filename>/dev/urandom</filename>), but
+ this can block not just during the boot process, but also much
+ later at run time, and generally results in a poor user
+ experience.
+ </para>
+ </section>
</chapter>
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 96/120: Add auto-generated XML for the Go
code snippets
by git repository hosting
This is an automated email from the git hooks/post-receive script.
sparks pushed a commit to branch master
in repository defensive-coding-guide.
commit a9229ae8c68586898bf6d49487c05e511131f7a1
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Fri May 30 14:29:22 2014 +0200
Add auto-generated XML for the Go code snippets
---
.../en-US/snippets/Go-Error_Handling-IO.xml | 25 ++++++++++++++++++++++
.../en-US/snippets/Go-Error_Handling-Regular.xml | 23 ++++++++++++++++++++
2 files changed, 48 insertions(+)
diff --git a/defensive-coding/en-US/snippets/Go-Error_Handling-IO.xml b/defensive-coding/en-US/snippets/Go-Error_Handling-IO.xml
new file mode 100644
index 0000000..818d1da
--- /dev/null
+++ b/defensive-coding/en-US/snippets/Go-Error_Handling-IO.xml
@@ -0,0 +1,25 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE programlisting PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+<!-- Automatically generated file. Do not edit. -->
+<programlisting language="C">
+func IOError(r io.Reader, buf []byte, processor Processor,
+ handler ErrorHandler) (message string, err error) {
+ n, err := r.Read(buf)
+ // First check for available data.
+ if n > 0 {
+ message, err = processor.Process(buf[0:n])
+ // Regular error handling.
+ if err != nil {
+ handler.Handle(err)
+ return "", err
+ }
+ }
+ // Then handle any error.
+ if err != nil {
+ handler.Handle(err)
+ return "", err
+ }
+ return
+}
+</programlisting>
diff --git a/defensive-coding/en-US/snippets/Go-Error_Handling-Regular.xml b/defensive-coding/en-US/snippets/Go-Error_Handling-Regular.xml
new file mode 100644
index 0000000..c7f4bc7
--- /dev/null
+++ b/defensive-coding/en-US/snippets/Go-Error_Handling-Regular.xml
@@ -0,0 +1,23 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE programlisting PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+<!-- Automatically generated file. Do not edit. -->
+<programlisting language="C">
+type Processor interface {
+ Process(buf []byte) (message string, err error)
+}
+
+type ErrorHandler interface {
+ Handle(err error)
+}
+
+func RegularError(buf []byte, processor Processor,
+ handler ErrorHandler) (message string, err error) {
+ message, err = processor.Process(buf)
+ if err != nil {
+ handler.Handle(err)
+ return "", err
+ }
+ return
+}
+</programlisting>
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 76/120: Add chapter on Go
by git repository hosting
This is an automated email from the git hooks/post-receive script.
sparks pushed a commit to branch master
in repository defensive-coding-guide.
commit 13faeec63da544dd64c453a5fd810f7b6d758dbd
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Mon May 26 14:58:01 2014 +0200
Add chapter on Go
---
defensive-coding/Makefile | 2 +-
defensive-coding/en-US/Defensive_Coding.xml | 1 +
defensive-coding/en-US/Go.xml | 90 +++++++++++++++++++++++++++++
defensive-coding/src/.gitignore | 1 +
defensive-coding/src/Go-Error_Handling.go | 48 +++++++++++++++
defensive-coding/src/src.mk | 6 ++
6 files changed, 147 insertions(+), 1 deletion(-)
diff --git a/defensive-coding/Makefile b/defensive-coding/Makefile
index 6220afc..2090dad 100644
--- a/defensive-coding/Makefile
+++ b/defensive-coding/Makefile
@@ -9,7 +9,7 @@ build: build-src build-manual
build-snippets:
mkdir -p en-US/snippets
python scripts/split-snippets.py . \
- src/*.c src/*.cpp src/*.java src/*.py
+ src/*.c src/*.cpp src/*.java src/*.py src/*.go
build-manual: build-snippets
publican build --formats=html,epub,pdf --langs=en-US
diff --git a/defensive-coding/en-US/Defensive_Coding.xml b/defensive-coding/en-US/Defensive_Coding.xml
index a9baeb3..ee96c8d 100644
--- a/defensive-coding/en-US/Defensive_Coding.xml
+++ b/defensive-coding/en-US/Defensive_Coding.xml
@@ -8,6 +8,7 @@
<xi:include href="CXX.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Java.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Python.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Go.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Vala.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
</part>
<part>
diff --git a/defensive-coding/en-US/Go.xml b/defensive-coding/en-US/Go.xml
new file mode 100644
index 0000000..0e44d5e
--- /dev/null
+++ b/defensive-coding/en-US/Go.xml
@@ -0,0 +1,90 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+<chapter id="chap-Defensive_Coding-Go">
+<title>The Go Programming Language</title>
+<para>
+ This chapter contains language-specific recommendations for Go.
+</para>
+<section id="chap-Defensive_Coding-Go-Memory_Safety">
+ <title>Memory safety</title>
+ <para>
+ Go provides memory safety, but only if the program is not executed
+ in parallel (that is, <envar>GOMAXPROCS</envar> is not larger than
+ <literal>1</literal>). The reason is that interface values and
+ slices consist of multiple words are not updated atomically.
+ Another thread of execution can observe an inconsistent pairing
+ between type information and stored value (for interfaces) or
+ pointer and length (for slices), and such inconsistency can lead
+ to a memory safety violation.
+ </para>
+ <para>
+ Code which does not run in parallel and does not use the
+ <literal>unsafe</literal> package (or other packages which expose
+ unsafe constructs) is memory-safe. For example, invalid casts and
+ out-of-range subscripting cause panics and run time.
+ </para>
+ <para>
+ Keep in mind that finalization can introduce parallelism because
+ finalizers are executed concurrently, potentially interleaved with
+ the rest of the program.
+ </para>
+</section>
+<section id="chap-Defensive_Coding-Go-Error_Handling">
+ <title>Error handling</title>
+ <para>
+ Only a few common operations (such as pointer dereference, integer
+ division, array subscripting) trigger exceptions in Go, called
+ <emphasis>panics</emphasis>. Most interfaces in the standard
+ library use a separate return value of type
+ <literal>error</literal> to signal error.
+ </para>
+ <para>
+ Not checking error return values can lead to incorrect operation
+ and data loss (especially in the case of writes, using interfaces
+ such as <literal>io.Writer</literal>).
+ </para>
+ <para>
+ The correct way to check error return values depends on the
+ function or method being called. In the majority of cases, the
+ first step after calling a function should be an error check
+ against the <literal>nil</literal> value, handling any encountered
+ error. See <xref
+ linkend="ex-Defensive_Coding-Go-Error_Handling-Regular"/> for
+ details.
+ </para>
+ <example id="ex-Defensive_Coding-Go-Error_Handling-Regular">
+ <title>Regular error handling in Go</title>
+ <xi:include href="snippets/Go-Error_Handling-Regular.xml"
+ xmlns:xi="http://www.w3.org/2001/XInclude" />
+ </example>
+ <para>
+ However, with <literal>io.Reader</literal>,
+ <literal>io.ReaderAt</literal> and related interfaces, it is
+ necessary to check for a non-zero number of read bytes first, as
+ shown in <xref
+ linkend="ex-Defensive_Coding-Go-Error_Handling-IO"/>. If this
+ pattern is not followed, data loss may occur. This is due to the
+ fact that the <literal>io.Reader</literal> interface permits
+ returning both data and an error at the same time.
+ </para>
+ <example id="ex-Defensive_Coding-Go-Error_Handling-IO">
+ <title>Read error handling in Go</title>
+ <xi:include href="snippets/Go-Error_Handling-IO.xml"
+ xmlns:xi="http://www.w3.org/2001/XInclude" />
+ </example>
+</section>
+<section id="chap-Defensive_Coding-Go-Garbage_Collector">
+ <title>Garbage Collector</title>
+ <para>
+ Older Go releases (before Go 1.3) use a conservative garbage
+ collector without blacklisting. This means that data blobs can
+ cause retention of unrelated data structures because the data is
+ conservatively interpreted as pointers. This phenomenon can be
+ triggered accidentally on 32-bit architectures and is more likely
+ to occur if the heap grows larger. On 64-bit architectures, it
+ may be possible to trigger it deliberately—it is unlikely to occur
+ spontaneously.
+ </para>
+</section>
+</chapter>
diff --git a/defensive-coding/src/.gitignore b/defensive-coding/src/.gitignore
index 4adbfe5..335a122 100644
--- a/defensive-coding/src/.gitignore
+++ b/defensive-coding/src/.gitignore
@@ -4,5 +4,6 @@
/TLS-Client-OpenSSL
/XML-Parser-Expat
/XML-Parser-Qt
+/Go-Error_Handling
*.class
*.o
diff --git a/defensive-coding/src/Go-Error_Handling.go b/defensive-coding/src/Go-Error_Handling.go
new file mode 100644
index 0000000..d546018
--- /dev/null
+++ b/defensive-coding/src/Go-Error_Handling.go
@@ -0,0 +1,48 @@
+package main
+
+import "io"
+
+//+ Go Error_Handling-Regular
+type Processor interface {
+ Process(buf []byte) (message string, err error)
+}
+
+type ErrorHandler interface {
+ Handle(err error)
+}
+
+func RegularError(buf []byte, processor Processor,
+ handler ErrorHandler) (message string, err error) {
+ message, err = processor.Process(buf)
+ if err != nil {
+ handler.Handle(err)
+ return "", err
+ }
+ return
+}
+//-
+
+//+ Go Error_Handling-IO
+func IOError(r io.Reader, buf []byte, processor Processor,
+ handler ErrorHandler) (message string, err error) {
+ n, err := r.Read(buf)
+ // First check for available data.
+ if n > 0 {
+ message, err = processor.Process(buf[0:n])
+ // Regular error handling.
+ if err != nil {
+ handler.Handle(err)
+ return "", err
+ }
+ }
+ // Then handle any error.
+ if err != nil {
+ handler.Handle(err)
+ return "", err
+ }
+ return
+}
+//-
+
+func main() {
+}
diff --git a/defensive-coding/src/src.mk b/defensive-coding/src/src.mk
index d47fc09..18bd592 100644
--- a/defensive-coding/src/src.mk
+++ b/defensive-coding/src/src.mk
@@ -2,10 +2,12 @@
CC = gcc
CXX = g++
+GCCGO = gccgo
CWARNFLAGS = -Wall -W -Wno-unused-parameter -Werror=implicit-function-declaration
CXXWARNFLAGS = -Wall -W
CFLAGS = -std=gnu99 -O2 $(CWARNFLAGS) -g
CXXFLAGS = -std=c++03 -O2 $(CXXWARNFLAGS) -g
+GOFLAGS = -O2 -Wall -W
LDFLAGS = -g
# List files which should only be compiled for syntax checking.
@@ -41,6 +43,7 @@ compile_and_link += XML-Parser-Expat
LIBS_XML-Parser-Expat = -lexpat
compile_and_link += XML-Parser-Qt
LIBS_XML-Parser-Qt = -lQtCore -lQtXml
+compile_and_link += Go-Error_Handling
# Define preprocessor symbols if certain functions exist.
CHECK_FUNCTION = crypto/X509_check_host/-DHAVE_X509_CHECK_HOST \
@@ -68,6 +71,9 @@ src/%.class: src/%.java
src/%: src/%.o
$(CXX) $(LDFLAGS) $^ -o $@ $(LIBS_$(notdir $@))
+src/%: src/%.go
+ $(GCCGO) $(GOFLAGS) $(LDFLAGS) -o $@ $^
+
src/TLS-Client-GNUTLS: src/tcp_connect.o
src/TLS-Client-OpenSSL: src/tcp_connect.o src/x509_check_host.o
src/TLS-Client-NSS: src/tcp_connect.o
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months