Patchwork [doc] extend.texi copy-editing, 4/N (bit-fields)

login
register
mail settings
Submitter Sandra Loosemore
Date Nov. 11, 2012, 2:51 a.m.
Message ID <509F12AB.4030605@codesourcery.com>
Download mbox | patch
Permalink /patch/198233/
State New
Headers show

Comments

Sandra Loosemore - Nov. 11, 2012, 2:51 a.m.
I've checked in this patch to consistently use "bit-field" in 
extend.texi instead of "bitfield" or "bit field".  "Bit-field" is listed 
in the GCC Coding Conventions as the preferred terminology, for 
consistency with the C and C++ standards.

-Sandra


2012-11-10  Sandra Loosemore  <sandra@codesourcery.com>

	gcc/
	* doc/extend.texi: Copy-edit to use "bit-field" consistently
	instead of "bitfield" or "bit field".

Patch

Index: gcc/doc/extend.texi
===================================================================
--- gcc/doc/extend.texi	(revision 193402)
+++ gcc/doc/extend.texi	(working copy)
@@ -5006,9 +5006,9 @@  Currently @option{-m[no-]ms-bitfields} i
 compilers to match the native Microsoft compiler.
 
 The Microsoft structure layout algorithm is fairly simple with the exception
-of the bitfield packing:
+of the bit-field packing:
 
-The padding and alignment of members of structures and whether a bit field
+The padding and alignment of members of structures and whether a bit-field
 can straddle a storage-unit boundary
 
 @enumerate
@@ -5025,19 +5025,19 @@  Every object is allocated an offset so t
 
 offset %  alignment-requirement == 0
 
-@item Adjacent bit fields are packed into the same 1-, 2-, or 4-byte allocation
-unit if the integral types are the same size and if the next bit field fits
+@item Adjacent bit-fields are packed into the same 1-, 2-, or 4-byte allocation
+unit if the integral types are the same size and if the next bit-field fits
 into the current allocation unit without crossing the boundary imposed by the
-common alignment requirements of the bit fields.
+common alignment requirements of the bit-fields.
 @end enumerate
 
-Handling of zero-length bitfields:
+Handling of zero-length bit-fields:
 
-MSVC interprets zero-length bitfields in the following ways:
+MSVC interprets zero-length bit-fields in the following ways:
 
 @enumerate
-@item If a zero-length bitfield is inserted between two bitfields that
-are normally coalesced, the bitfields are not coalesced.
+@item If a zero-length bit-field is inserted between two bit-fields that
+are normally coalesced, the bit-fields are not coalesced.
 
 For example:
 
@@ -5050,12 +5050,12 @@  struct
  @} t1;
 @end smallexample
 
-The size of @code{t1} is 8 bytes with the zero-length bitfield.  If the
-zero-length bitfield were removed, @code{t1}'s size would be 4 bytes.
+The size of @code{t1} is 8 bytes with the zero-length bit-field.  If the
+zero-length bit-field were removed, @code{t1}'s size would be 4 bytes.
 
-@item If a zero-length bitfield is inserted after a bitfield, @code{foo}, and the
-alignment of the zero-length bitfield is greater than the member that follows it,
-@code{bar}, @code{bar} is aligned as the type of the zero-length bitfield.
+@item If a zero-length bit-field is inserted after a bit-field, @code{foo}, and the
+alignment of the zero-length bit-field is greater than the member that follows it,
+@code{bar}, @code{bar} is aligned as the type of the zero-length bit-field.
 
 For example:
 
@@ -5077,18 +5077,18 @@  struct
 
 For @code{t2}, @code{bar} is placed at offset 2, rather than offset 1.
 Accordingly, the size of @code{t2} is 4.  For @code{t3}, the zero-length
-bitfield does not affect the alignment of @code{bar} or, as a result, the size
+bit-field does not affect the alignment of @code{bar} or, as a result, the size
 of the structure.
 
 Taking this into account, it is important to note the following:
 
 @enumerate
-@item If a zero-length bitfield follows a normal bitfield, the type of the
-zero-length bitfield may affect the alignment of the structure as whole. For
-example, @code{t2} has a size of 4 bytes, since the zero-length bitfield follows a
-normal bitfield, and is of type short.
+@item If a zero-length bit-field follows a normal bit-field, the type of the
+zero-length bit-field may affect the alignment of the structure as whole. For
+example, @code{t2} has a size of 4 bytes, since the zero-length bit-field follows a
+normal bit-field, and is of type short.
 
-@item Even if a zero-length bitfield is not followed by a normal bitfield, it may
+@item Even if a zero-length bit-field is not followed by a normal bit-field, it may
 still affect the alignment of the structure:
 
 @smallexample
@@ -5102,7 +5102,7 @@  struct
 Here, @code{t4} takes up 4 bytes.
 @end enumerate
 
-@item Zero-length bitfields following non-bitfield members are ignored:
+@item Zero-length bit-fields following non-bit-field members are ignored:
 
 @smallexample
 struct
@@ -5266,7 +5266,7 @@  alignment.  See your linker documentatio
 
 @item packed
 This attribute, attached to @code{struct} or @code{union} type
-definition, specifies that each member (other than zero-width bitfields)
+definition, specifies that each member (other than zero-width bit-fields)
 of the structure or union is placed to minimize the memory required.  When
 attached to an @code{enum} definition, it indicates that the smallest
 integral type should be used.
@@ -5782,11 +5782,11 @@  If you need to read the volatile object 
 occurred, you must use a separate expression with an intervening
 sequence point.
 
-As bitfields are not individually addressable, volatile bitfields may
-be implicitly read when written to, or when adjacent bitfields are
-accessed.  Bitfield operations may be optimized such that adjacent
-bitfields are only partially accessed, if they straddle a storage unit
-boundary.  For these reasons it is unwise to use volatile bitfields to
+As bit-fields are not individually addressable, volatile bit-fields may
+be implicitly read when written to, or when adjacent bit-fields are
+accessed.  Bit-field operations may be optimized such that adjacent
+bit-fields are only partially accessed, if they straddle a storage unit
+boundary.  For these reasons it is unwise to use volatile bit-fields to
 access hardware.
 
 @node Extended Asm
@@ -14485,7 +14485,7 @@  always the C-language name.
 
 For compatibility with Microsoft Windows compilers, GCC supports a
 set of @code{#pragma} directives that change the maximum alignment of
-members of structures (other than zero-width bitfields), unions, and
+members of structures (other than zero-width bit-fields), unions, and
 classes subsequently defined. The @var{n} value below always is required
 to be a small power of two and specifies the new alignment in bytes.