Bug 315 - documentation correction for obstack alignment
Summary: documentation correction for obstack alignment
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: manual (show other bugs)
Version: 2.3.3
: P2 normal
Target Milestone: ---
Assignee: Roland McGrath
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-08-10 04:45 UTC by Paul Eggert
Modified: 2019-04-10 11:13 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Eggert 2004-08-10 04:45:14 UTC
2004-08-09  Paul Eggert  <eggert@cs.ucla.edu>

	* manual/memory.texi (Obstacks Data Alignment): The default
	alignment is not 4: it is enough to hold any type of data.
	Problem reported by Benno in
	<http://sources.redhat.com/ml/libc-alpha/2004-08/msg00055.html>.

--- memory.texi	2003-02-25 02:10:35 -0800
+++ /home/eggert/junk/memory.texi	2004-08-09 21:39:42 -0700
@@ -1968,7 +1968,8 @@ obstack_next_free (@var{obstack-ptr}) - 
 
 Each obstack has an @dfn{alignment boundary}; each object allocated in
 the obstack automatically starts on an address that is a multiple of the
-specified boundary.  By default, this boundary is 4 bytes.
+specified boundary.  By default, this boundary is aligned so that
+the object can hold any type of data.
 
 To access an obstack's alignment boundary, use the macro
 @code{obstack_alignment_mask}, whose function prototype looks like
@@ -1980,7 +1981,9 @@ this:
 The value is a bit mask; a bit that is 1 indicates that the corresponding
 bit in the address of an object should be 0.  The mask value should be one
 less than a power of 2; the effect is that all object addresses are
-multiples of that power of 2.  The default value of the mask is 3, so that
+multiples of that power of 2.  The default value of the mask is a value
+that allows aligned objects to hold any type of data: for example, if
+its value is 3, any type of data can be stored at locations whose
 addresses are multiples of 4.  A mask value of 0 means an object can start
 on any multiple of 1 (that is, no alignment is required).
Comment 1 Jakub Jelinek 2004-08-10 07:24:43 UTC
But DEFAULT_ALIGNMENT in obstack is not big enough to hold any data type.
It is the alignment of double.
It can be changed if obstack_specify_allocation* macros are used in place of
obstack_init or obstack_begin.
Comment 2 Paul Eggert 2004-08-11 23:35:37 UTC
DEFAULT_ALIGNMENT is the alignment of double only because of a
historical accident: when that code was originally written, the
alignment of double was the strictest for each host.  The intent was
that the default alignment would suffice, and that you can specify
a stricter alignment if you know what it is.

Typical obstack usage (e.g., the GCC source code, the Bison source
code) looks like this:

#if !defined(__GNUC__) || (__GNUC__ < 2)
#define __alignof__(type) 0
#endif
	      obstack_specify_allocation (&bitmap_obstack, OBSTACK_CHUNK_SIZE,
					  __alignof__ (bitmap_element),
					  obstack_chunk_alloc,
					  obstack_chunk_free);


and hence if GCC and/or Bison is compiled by a non-GCC compiler, the
obstack code will use the default alignment.  This typical usage works
in general only if the default alignment suffices for all types.

Also please see Bugzilla Bug 321
<http://sources.redhat.com/bugzilla/show_bug.cgi?id=321>;
once that patch is installed the alignment will no longer
necessarily be that of "double".
Comment 3 cvs-commit@gcc.gnu.org 2006-02-22 06:58:03 UTC
Subject: Bug 315

CVSROOT:	/cvs/glibc
Module name:	libc
Changes by:	roland@sources.redhat.com	2006-02-22 06:57:59

Modified files:
	manual         : memory.texi 

Log message:
	2004-08-09  Paul Eggert  <eggert@cs.ucla.edu>
	
	[BZ #315]
	* manual/memory.texi (Obstacks Data Alignment): The default
	alignment is not 4: it is enough to hold any type of data.
	Problem reported by Benno in
	<http://sources.redhat.com/ml/libc-alpha/2004-08/msg00055.html>.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/manual/memory.texi.diff?cvsroot=glibc&r1=1.80&r2=1.81

Comment 4 Roland McGrath 2006-02-22 06:58:37 UTC
I put the change in.