[defensive-coding-guide] 75/120: Add a short chapter on Vala
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 2988ebd27e73444ca8b9c197fa35e8be7e92a620
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Mon May 26 11:46:16 2014 +0200
Add a short chapter on Vala
---
defensive-coding/en-US/Defensive_Coding.xml | 1 +
defensive-coding/en-US/Vala.xml | 53 +++++++++++++++++++++++++++++
2 files changed, 54 insertions(+)
diff --git a/defensive-coding/en-US/Defensive_Coding.xml b/defensive-coding/en-US/Defensive_Coding.xml
index 7ca3f46..a9baeb3 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="Vala.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
</part>
<part>
<title>Specific Programming Tasks</title>
diff --git a/defensive-coding/en-US/Vala.xml b/defensive-coding/en-US/Vala.xml
new file mode 100644
index 0000000..3dea943
--- /dev/null
+++ b/defensive-coding/en-US/Vala.xml
@@ -0,0 +1,53 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+<chapter id="chap-Defensive_Coding-Vala">
+<title>The Vala Programming Language</title>
+<para>
+ Vala is a programming language mainly targeted at GNOME developers.
+</para>
+<para>
+ Its syntax is inspired by C# (and thus, indirectly, by Java). But
+ 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 <xref linkend="chap-Defensive_Coding-C"/> apply.
+</para>
+<para>
+ In particular, the following Vala language constructs can result in
+ undefined behavior at run time:
+</para>
+<itemizedlist>
+ <listitem>
+ <para>
+ Integer arithmetic, as described in <xref
+ linkend="sect-Defensive_Coding-C-Arithmetic"/>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Pointer arithmetic, string subscripting and the
+ <literal>substring</literal> method on strings (the
+ <literal>string</literal> class in the
+ <literal>glib-2.0</literal> package) are not range-checked. It
+ is the responsibility of the calling code to ensure that the
+ arguments being passed are valid. This applies even to cases
+ (like <literal>substring</literal>) where the implementation
+ would have range information to check the validity of indexes.
+ See <xref linkend="sect-Defensive_Coding-C-Pointers"/>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Similarly, Vala only performs garbage collection (through
+ reference counting) for <literal>GObject</literal> 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 <xref
+ linkend="sect-Defensive_Coding-C-Use-After-Free"/>).
+ </para>
+ </listitem>
+</itemizedlist>
+</chapter>
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 74/120:
sect-Defensive_Coding-C-Use-After-Free: New section ID
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 199b3edb08f9ff5531dba1910e6a3d76e56c5006
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Mon May 26 11:33:41 2014 +0200
sect-Defensive_Coding-C-Use-After-Free: New section ID
---
defensive-coding/en-US/C-Allocators.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/defensive-coding/en-US/C-Allocators.xml b/defensive-coding/en-US/C-Allocators.xml
index 58c89ee..87d2682 100644
--- a/defensive-coding/en-US/C-Allocators.xml
+++ b/defensive-coding/en-US/C-Allocators.xml
@@ -29,7 +29,7 @@
realloc(ptr, size);</literal> is wrong because the memory
pointed to by <literal>ptr</literal> leaks in case of an error.
</para>
- <section>
+ <section id="sect-Defensive_Coding-C-Use-After-Free">
<title>Use-after-free errors</title>
<para>
After <function>free</function>, the pointer is invalid.
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 73/120: TLS: More balanced advice on
"openssl genrsa" and /dev/urandom
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 7f640d95375def0979c9f6a12c02cd414fe1eb7e
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Mon Apr 28 15:41:05 2014 +0200
TLS: More balanced advice on "openssl genrsa" and /dev/urandom
---
defensive-coding/en-US/Features-TLS.xml | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/defensive-coding/en-US/Features-TLS.xml b/defensive-coding/en-US/Features-TLS.xml
index f4da007..5d9e39d 100644
--- a/defensive-coding/en-US/Features-TLS.xml
+++ b/defensive-coding/en-US/Features-TLS.xml
@@ -190,9 +190,11 @@
genrsa</command>, do not ensure that physical entropy is used
for key generation—they obtain entropy from
<filename>/dev/urandom</filename> and other sources, but not
- from <filename>/dev/random</filename>. Keys generated by
- these tools should not be used in high-value, critical
- functions.
+ from <filename>/dev/random</filename>. This can result in
+ weak keys if the system lacks a proper entropy source (e.g., a
+ virtual machine with solid state storage). Depending on local
+ policies, keys generated by these OpenSSL tools should not be
+ used in high-value, critical functions.
</para>
<para>
The OpenSSL server and client applications (<command>openssl
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 72/120: RPM packaging: X.509 key pair
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 95c297659e14411959ae36ae6a3a29a550c668c0
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Fri Apr 25 16:33:08 2014 +0200
RPM packaging: X.509 key pair generation
---
defensive-coding/en-US/Defensive_Coding.xml | 1 +
defensive-coding/en-US/Tasks-Packaging.xml | 131 ++++++++++++++++++++++++++++
2 files changed, 132 insertions(+)
diff --git a/defensive-coding/en-US/Defensive_Coding.xml b/defensive-coding/en-US/Defensive_Coding.xml
index b8ca3de..7ca3f46 100644
--- a/defensive-coding/en-US/Defensive_Coding.xml
+++ b/defensive-coding/en-US/Defensive_Coding.xml
@@ -18,6 +18,7 @@
<xi:include href="Tasks-Processes.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Tasks-Serialization.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Tasks-Cryptography.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Tasks-Packaging.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
</part>
<part>
<title>Implementing Security Features</title>
diff --git a/defensive-coding/en-US/Tasks-Packaging.xml b/defensive-coding/en-US/Tasks-Packaging.xml
new file mode 100644
index 0000000..95bfbc6
--- /dev/null
+++ b/defensive-coding/en-US/Tasks-Packaging.xml
@@ -0,0 +1,131 @@
+<?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-Tasks-Packaging">
+ <title>RPM packaging</title>
+ <para>
+ This chapter deals with security-related concerns around RPM
+ packaging. It has to be read in conjunction with
+ distribution-specific packaging guidelines.
+ </para>
+ <section id="sect-Defensive_Coding-Tasks-Packaging-Certificates">
+ <title>Generating X.509 self-signed certificates during
+ installation</title>
+ <para>
+ Some applications need X.509 certificates for authentication
+ purposes. For example, a single private/public key pair could
+ be used to define cluster membership, enabling authentication
+ and encryption of all intra-cluster communication. (Lack of
+ certification from a CA matters less in such a context.) For
+ 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.
+ </para>
+ <important>
+ <para>
+ The way the key is generated may not be suitable for key
+ material of critical value. (<command>openssl
+ genrsa</command> uses, but does not require, entropy from a
+ physical source of randomness, among other things.) Such keys
+ should be stored in a hardware security module if possible,
+ and generated from random bits reserved for this purpose
+ derived from a non-deterministic physical source.
+ </para>
+ </important>
+ <para>
+ In the spec file, we define two RPM variables which contain the
+ names of the files used to store the private and public key, and
+ the user name for the service:
+ </para>
+ <informalexample>
+ <programlisting language="RPM Spec">
+# Name of the user owning the file with the private key
+%define tlsuser %{name}
+# Name of the directory which contains the key and certificate files
+%define tlsdir %{_sysconfdir}/%{name}
+%define tlskey %{tlsdir}/%{name}.key
+%define tlscert %{tlsdir}/%{name}.crt
+ </programlisting>
+ </informalexample>
+ <para>
+ These variables likely need adjustment based on the needs of the
+ package.
+ </para>
+ <para>
+ Typically, the file with the private key needs to be owned by
+ the system user which needs to read it,
+ <literal>%{tlsuser}</literal> (not <literal>root</literal>). In
+ order to avoid races, if the <emphasis>directory</emphasis>
+ <literal>%{tlsdir}</literal> is <emphasis>owned by the services
+ user</emphasis>, you should use the code in <xref
+ linkend="ex-Defensive_Coding-Packaging-Certificates-Owned"/>.
+ The invocation of <application>su</application> with the
+ <option>-s /bin/bash</option> argument is necessary in case the
+ login shell for the user has been disabled.
+ </para>
+ <example id="ex-Defensive_Coding-Packaging-Certificates-Owned">
+ <title>Creating a key pair in a user-owned directory</title>
+ <programlisting language="Bash">
+%post
+if [ $1 -eq 1 ] ; then
+ if ! test -e %{tlskey} ; then
+ su -s /bin/bash \
+ -c "umask 077 && openssl genrsa -out %{tlskey} 2048 2>/dev/null" \
+ %{tlsuser}
+ fi
+ if ! test -e %{tlscert} ; then
+ cn="Automatically generated certificate for the %{tlsuser} service"
+ req_args="-key %{tlskey} -out %{tlscert} -days 7305 -subj \"/CN=$cn/\""
+ su -s /bin/bash \
+ -c "openssl req -new -x509 -extensions usr_cert $req_args" \
+ %{tlsuser}
+ fi
+fi
+
+%files
+%dir %attr(0755,%{tlsuser},%{tlsuser]) %{tlsdir}
+%ghost %attr(0600,%{tlsuser},%{tlsuser}) %{tlskey}
+%ghost %attr(0644,%{tlsuser},%{tlsuser}) %{tlscert}
+ </programlisting>
+ </example>
+ <para>
+ If the <emphasis>directory</emphasis>
+ <literal>%{tlsdir}</literal> <emphasis>is owned by</emphasis>
+ <literal>root</literal>, use the code in <xref
+ linkend="ex-Defensive_Coding-Packaging-Certificates-Unowned"/>.
+ </para>
+ <example id="ex-Defensive_Coding-Packaging-Certificates-Unowned">
+ <title>Creating a key pair in a <literal>root</literal>-owned directory</title>
+ <programlisting language="Bash">
+%post
+if [ $1 -eq 1 ] ; then
+ if ! test -e %{tlskey} ; then
+ (umask 077 && openssl genrsa -out %{tlskey} 2048 2>/dev/null)
+ chown %{tlsuser} %{tlskey}
+ fi
+ if ! test -e %{tlscert} ; then
+ cn="Automatically generated certificate for the %{tlsuser} service"
+ openssl req -new -x509 -extensions usr_cert \
+ -key %{tlskey} -out %{tlscert} -days 7305 -subj "/CN=$cn/"
+ fi
+fi
+
+%files
+%dir %attr(0755,%{root},%{root}]) %{tlsdir}
+%ghost %attr(0600,%{tlsuser},%{tlsuser}) %{tlskey}
+%ghost %attr(0644,%{root},%{root}) %{tlscert}
+ </programlisting>
+ </example>
+ <para>
+ In order for this to work, the package which generates the keys
+ must require the <application>openssl</application> package. If
+ the user which owns the key file is generated by a different
+ package, the package generating the certificate must specify a
+ <literal>Requires(pre):</literal> on the package which creates
+ the user. This ensures that the user account will exist when it
+ is needed for the <application>su</application> or
+ <application>chmod</application> invocation.
+ </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] 71/120: sect-Defensive_Coding-TLS-OpenSSL:
Mention "openssl genrsa" entropy 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 564ffc80149307d0a99724e2689ed3a8816513bf
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Fri Apr 25 13:47:22 2014 +0200
sect-Defensive_Coding-TLS-OpenSSL: Mention "openssl genrsa" entropy issue
---
defensive-coding/en-US/Features-TLS.xml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/defensive-coding/en-US/Features-TLS.xml b/defensive-coding/en-US/Features-TLS.xml
index 936910d..f4da007 100644
--- a/defensive-coding/en-US/Features-TLS.xml
+++ b/defensive-coding/en-US/Features-TLS.xml
@@ -186,6 +186,15 @@
verify</command> result in an exit status of zero.
</para>
<para>
+ OpenSSL command-line commands, such as <command>openssl
+ genrsa</command>, do not ensure that physical entropy is used
+ for key generation—they obtain entropy from
+ <filename>/dev/urandom</filename> and other sources, but not
+ from <filename>/dev/random</filename>. Keys generated by
+ these tools should not be used in high-value, critical
+ functions.
+ </para>
+ <para>
The OpenSSL server and client applications (<command>openssl
s_client</command> and <command>openssl s_server</command>)
are debugging tools and should <emphasis>never</emphasis> be
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 70/120: Custom memory allocators: Complete
sentence
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 eff2f5c71f3cd02e603dcd9e616a332f3490a0db
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Thu Apr 10 21:10:41 2014 +0200
Custom memory allocators: Complete sentence
Also add section ID.
---
defensive-coding/en-US/C-Allocators.xml | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/defensive-coding/en-US/C-Allocators.xml b/defensive-coding/en-US/C-Allocators.xml
index 1bff610..58c89ee 100644
--- a/defensive-coding/en-US/C-Allocators.xml
+++ b/defensive-coding/en-US/C-Allocators.xml
@@ -140,7 +140,7 @@
</para>
</section>
- <section>
+ <section id="sect-Defensive_Coding-C-Allocators-Custom">
<title>Custom memory allocators</title>
<para>
Custom memory allocates come in two forms: replacements for
@@ -176,7 +176,8 @@
allocators. In micro-benchmarks, pool allocators can show
huge wins, and size-specific pools can reduce internal
fragmentation. But often, utilization of individual pools
- is poor, and
+ is poor, and external fragmentation increases the overall
+ memory usage.
</para>
</listitem>
</itemizedlist>
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 65/120: Fix typos spotted by Kamil Dudka
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 39e08eb0e4bd694b7856be4bfe33284434c53e95
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Mon Dec 2 14:38:10 2013 +0100
Fix typos spotted by Kamil Dudka
---
defensive-coding/en-US/C-Language.xml | 2 +-
defensive-coding/en-US/Tasks-Processes.xml | 4 ++--
defensive-coding/en-US/Tasks-Temporary_Files.xml | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/defensive-coding/en-US/C-Language.xml b/defensive-coding/en-US/C-Language.xml
index f50e36c..b1eeec0 100644
--- a/defensive-coding/en-US/C-Language.xml
+++ b/defensive-coding/en-US/C-Language.xml
@@ -123,7 +123,7 @@
xmlns:xi="http://www.w3.org/2001/XInclude" />
</example>
<para>
- Basic arithmetic operations a commutative, so for bounds checks,
+ Basic arithmetic operations are 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.
diff --git a/defensive-coding/en-US/Tasks-Processes.xml b/defensive-coding/en-US/Tasks-Processes.xml
index 90f01f0..141232a 100644
--- a/defensive-coding/en-US/Tasks-Processes.xml
+++ b/defensive-coding/en-US/Tasks-Processes.xml
@@ -24,7 +24,7 @@
<para>
The configured program name should be an absolute path. If it
is a relative path, the contents of the <envar>PATH</envar>
- must be obtained in s secure manner (see <xref
+ must be obtained in a secure manner (see <xref
linkend="sect-Defensive_Coding-Tasks-secure_getenv"/>).
If the <envar>PATH</envar> variable is not set or untrusted,
the safe default <literal>/bin:/usr/bin</literal> must be
@@ -290,7 +290,7 @@
<para>
At the moment, the parent process should explicitly wait for
termination of the child process using
- <function>waitpid</function> or <function>waitpid</function>,
+ <function>waitpid</function> or <function>waitid</function>,
and hope that the status is not collected by an event loop
first.
</para>
diff --git a/defensive-coding/en-US/Tasks-Temporary_Files.xml b/defensive-coding/en-US/Tasks-Temporary_Files.xml
index d78bad7..45cefdf 100644
--- a/defensive-coding/en-US/Tasks-Temporary_Files.xml
+++ b/defensive-coding/en-US/Tasks-Temporary_Files.xml
@@ -6,7 +6,7 @@
<para>
In this chapter, we describe how to create temporary files and
directories, how to remove them, and how to work with programs
- which do not create files in ways that a safe with a shared
+ which do not create files in ways that are safe with a shared
directory for temporary files. General file system manipulation
is treated in a separate chapter, <xref
linkend="chap-Defensive_Coding-Tasks-File_System"/>.
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 64/120: C Language: Mention mixed
signed/unsigned comparisons
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 ace93c0dd61b3da84e8bf78e1fc50f4426ff5c55
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Wed Oct 30 20:42:26 2013 +0100
C Language: Mention mixed signed/unsigned comparisons
---
defensive-coding/en-US/C-Language.xml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/defensive-coding/en-US/C-Language.xml b/defensive-coding/en-US/C-Language.xml
index b039ed2..f50e36c 100644
--- a/defensive-coding/en-US/C-Language.xml
+++ b/defensive-coding/en-US/C-Language.xml
@@ -141,6 +141,20 @@
lot when implementing overflow checks.
</para>
<para>
+ Sometimes, it is necessary to compare unsigned and signed
+ integer variables. This results in a compiler warning,
+ <emphasis>comparison between signed and unsigned integer
+ expressions</emphasis>, because the comparison often gives
+ unexpected results for negative values. When adding a cast,
+ make sure that negative values are covered properly. If the
+ bound is unsigned and the checked quantity is signed, you should
+ cast the checked quantity to an unsigned type as least as wide
+ as either operand type. As a result, negative values will fail
+ the bounds check. (You can still check for negative values
+ separately for clarity, and the compiler will optimize away this
+ redundant check.)
+ </para>
+ <para>
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
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 63/120: Update the README file
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 a2df781c2b364f3f8fc7cef13a820896019c8f0a
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Thu Sep 19 17:07:03 2013 +0200
Update the README file
---
defensive-coding/README | 26 ++++++++++----------------
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/defensive-coding/README b/defensive-coding/README
index 934d2a2..58d0ae8 100644
--- a/defensive-coding/README
+++ b/defensive-coding/README
@@ -1,14 +1,17 @@
-TODO items
-----------
+TODO and bug tracking
+---------------------
-Suggested items for inclusion are listed here:
+The secure-coding guide has its own component in Bugzilla:
-https://engineering.redhat.com/trac/product-security/wiki/DefensiveCodingTODO
+https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20Documentation&component=defensive-coding-guide
+
+Please file bugs and suggestions there.
Building HTML documentation
---------------------------
-Just type "make".
+Just type "make". If you do not want to build the example code, run
+"make build-manual".
When you type "make", the code examples in src/ are compiled (mainly
to check for obvious syntax errors, but also for manual testing). If
@@ -19,14 +22,5 @@ included in the manual.
Dependencies
------------
-Building the manual needs the "publican" package and the
-"publican-redhat-engservices" package available here:
-
-http://download.lab.bos.redhat.com/brewroot/packages/publican-redhat-engservices/
-
-Version 0.4 of the publican-redhat-engservices package needs publican
-3.0. This version of the package:
-
-http://download.lab.bos.redhat.com/brewroot/packages/publican-redhat-engservices/0.3/2.el6eng/noarch/publican-redhat-engservices-0.3-2.el6eng.noarch.rpm
-
-is known to work with publican 2.8 available in Fedora 17.
+Building the manual needs the "publican" and the "publican-fedora"
+packages.
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months
[defensive-coding-guide] 62/120: C++: Mention front(),
back() and data() member functions of vectors
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 7db67ea9b35a0cb04a0b68048802950775558579
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Thu Sep 19 15:15:28 2013 +0200
C++: Mention front(), back() and data() member functions of vectors
---
defensive-coding/en-US/CXX-Std.xml | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/defensive-coding/en-US/CXX-Std.xml b/defensive-coding/en-US/CXX-Std.xml
index 56e1ad0..155f70c 100644
--- a/defensive-coding/en-US/CXX-Std.xml
+++ b/defensive-coding/en-US/CXX-Std.xml
@@ -163,6 +163,15 @@
<literal>operator[](size_type)</literal>, even though it is
slightly more verbose.
</para>
+ <para>
+ The <literal>front()</literal> and <literal>back()</literal>
+ member functions are undefined if a vector object is empty. You
+ can use <literal>vec.at(0)</literal> and
+ <literal>vec.at(vec.size() - 1)</literal> as checked
+ replacements. For an empty vector, <literal>data()</literal> is
+ defined; it returns an arbitrary pointer, but not necessarily
+ the NULL pointer.
+ </para>
</section>
<section id="sect-Defensive_Coding-CXX-Std-Iterators">
<title>Iterators</title>
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
7 years, 8 months