1 |
227 |
jeremybenn |
@node Obstacks,Licenses,Functions,Top
|
2 |
|
|
@chapter Obstacks
|
3 |
|
|
@cindex obstacks
|
4 |
|
|
|
5 |
|
|
An @dfn{obstack} is a pool of memory containing a stack of objects. You
|
6 |
|
|
can create any number of separate obstacks, and then allocate objects in
|
7 |
|
|
specified obstacks. Within each obstack, the last object allocated must
|
8 |
|
|
always be the first one freed, but distinct obstacks are independent of
|
9 |
|
|
each other.
|
10 |
|
|
|
11 |
|
|
Aside from this one constraint of order of freeing, obstacks are totally
|
12 |
|
|
general: an obstack can contain any number of objects of any size. They
|
13 |
|
|
are implemented with macros, so allocation is usually very fast as long as
|
14 |
|
|
the objects are usually small. And the only space overhead per object is
|
15 |
|
|
the padding needed to start each object on a suitable boundary.
|
16 |
|
|
|
17 |
|
|
@menu
|
18 |
|
|
* Creating Obstacks:: How to declare an obstack in your program.
|
19 |
|
|
* Preparing for Obstacks:: Preparations needed before you can
|
20 |
|
|
use obstacks.
|
21 |
|
|
* Allocation in an Obstack:: Allocating objects in an obstack.
|
22 |
|
|
* Freeing Obstack Objects:: Freeing objects in an obstack.
|
23 |
|
|
* Obstack Functions:: The obstack functions are both
|
24 |
|
|
functions and macros.
|
25 |
|
|
* Growing Objects:: Making an object bigger by stages.
|
26 |
|
|
* Extra Fast Growing:: Extra-high-efficiency (though more
|
27 |
|
|
complicated) growing objects.
|
28 |
|
|
* Status of an Obstack:: Inquiries about the status of an obstack.
|
29 |
|
|
* Obstacks Data Alignment:: Controlling alignment of objects in obstacks.
|
30 |
|
|
* Obstack Chunks:: How obstacks obtain and release chunks;
|
31 |
|
|
efficiency considerations.
|
32 |
|
|
* Summary of Obstacks::
|
33 |
|
|
@end menu
|
34 |
|
|
|
35 |
|
|
@node Creating Obstacks
|
36 |
|
|
@section Creating Obstacks
|
37 |
|
|
|
38 |
|
|
The utilities for manipulating obstacks are declared in the header
|
39 |
|
|
file @file{obstack.h}.
|
40 |
|
|
@pindex obstack.h
|
41 |
|
|
|
42 |
|
|
@comment obstack.h
|
43 |
|
|
@comment GNU
|
44 |
|
|
@deftp {Data Type} {struct obstack}
|
45 |
|
|
An obstack is represented by a data structure of type @code{struct
|
46 |
|
|
obstack}. This structure has a small fixed size; it records the status
|
47 |
|
|
of the obstack and how to find the space in which objects are allocated.
|
48 |
|
|
It does not contain any of the objects themselves. You should not try
|
49 |
|
|
to access the contents of the structure directly; use only the functions
|
50 |
|
|
described in this chapter.
|
51 |
|
|
@end deftp
|
52 |
|
|
|
53 |
|
|
You can declare variables of type @code{struct obstack} and use them as
|
54 |
|
|
obstacks, or you can allocate obstacks dynamically like any other kind
|
55 |
|
|
of object. Dynamic allocation of obstacks allows your program to have a
|
56 |
|
|
variable number of different stacks. (You can even allocate an
|
57 |
|
|
obstack structure in another obstack, but this is rarely useful.)
|
58 |
|
|
|
59 |
|
|
All the functions that work with obstacks require you to specify which
|
60 |
|
|
obstack to use. You do this with a pointer of type @code{struct obstack
|
61 |
|
|
*}. In the following, we often say ``an obstack'' when strictly
|
62 |
|
|
speaking the object at hand is such a pointer.
|
63 |
|
|
|
64 |
|
|
The objects in the obstack are packed into large blocks called
|
65 |
|
|
@dfn{chunks}. The @code{struct obstack} structure points to a chain of
|
66 |
|
|
the chunks currently in use.
|
67 |
|
|
|
68 |
|
|
The obstack library obtains a new chunk whenever you allocate an object
|
69 |
|
|
that won't fit in the previous chunk. Since the obstack library manages
|
70 |
|
|
chunks automatically, you don't need to pay much attention to them, but
|
71 |
|
|
you do need to supply a function which the obstack library should use to
|
72 |
|
|
get a chunk. Usually you supply a function which uses @code{malloc}
|
73 |
|
|
directly or indirectly. You must also supply a function to free a chunk.
|
74 |
|
|
These matters are described in the following section.
|
75 |
|
|
|
76 |
|
|
@node Preparing for Obstacks
|
77 |
|
|
@section Preparing for Using Obstacks
|
78 |
|
|
|
79 |
|
|
Each source file in which you plan to use the obstack functions
|
80 |
|
|
must include the header file @file{obstack.h}, like this:
|
81 |
|
|
|
82 |
|
|
@smallexample
|
83 |
|
|
#include <obstack.h>
|
84 |
|
|
@end smallexample
|
85 |
|
|
|
86 |
|
|
@findex obstack_chunk_alloc
|
87 |
|
|
@findex obstack_chunk_free
|
88 |
|
|
Also, if the source file uses the macro @code{obstack_init}, it must
|
89 |
|
|
declare or define two functions or macros that will be called by the
|
90 |
|
|
obstack library. One, @code{obstack_chunk_alloc}, is used to allocate
|
91 |
|
|
the chunks of memory into which objects are packed. The other,
|
92 |
|
|
@code{obstack_chunk_free}, is used to return chunks when the objects in
|
93 |
|
|
them are freed. These macros should appear before any use of obstacks
|
94 |
|
|
in the source file.
|
95 |
|
|
|
96 |
|
|
Usually these are defined to use @code{malloc} via the intermediary
|
97 |
|
|
@code{xmalloc} (@pxref{Unconstrained Allocation, , , libc, The GNU C Library Reference Manual}). This is done with
|
98 |
|
|
the following pair of macro definitions:
|
99 |
|
|
|
100 |
|
|
@smallexample
|
101 |
|
|
#define obstack_chunk_alloc xmalloc
|
102 |
|
|
#define obstack_chunk_free free
|
103 |
|
|
@end smallexample
|
104 |
|
|
|
105 |
|
|
@noindent
|
106 |
|
|
Though the memory you get using obstacks really comes from @code{malloc},
|
107 |
|
|
using obstacks is faster because @code{malloc} is called less often, for
|
108 |
|
|
larger blocks of memory. @xref{Obstack Chunks}, for full details.
|
109 |
|
|
|
110 |
|
|
At run time, before the program can use a @code{struct obstack} object
|
111 |
|
|
as an obstack, it must initialize the obstack by calling
|
112 |
|
|
@code{obstack_init}.
|
113 |
|
|
|
114 |
|
|
@comment obstack.h
|
115 |
|
|
@comment GNU
|
116 |
|
|
@deftypefun int obstack_init (struct obstack *@var{obstack-ptr})
|
117 |
|
|
Initialize obstack @var{obstack-ptr} for allocation of objects. This
|
118 |
|
|
function calls the obstack's @code{obstack_chunk_alloc} function. If
|
119 |
|
|
allocation of memory fails, the function pointed to by
|
120 |
|
|
@code{obstack_alloc_failed_handler} is called. The @code{obstack_init}
|
121 |
|
|
function always returns 1 (Compatibility notice: Former versions of
|
122 |
|
|
obstack returned 0 if allocation failed).
|
123 |
|
|
@end deftypefun
|
124 |
|
|
|
125 |
|
|
Here are two examples of how to allocate the space for an obstack and
|
126 |
|
|
initialize it. First, an obstack that is a static variable:
|
127 |
|
|
|
128 |
|
|
@smallexample
|
129 |
|
|
static struct obstack myobstack;
|
130 |
|
|
@dots{}
|
131 |
|
|
obstack_init (&myobstack);
|
132 |
|
|
@end smallexample
|
133 |
|
|
|
134 |
|
|
@noindent
|
135 |
|
|
Second, an obstack that is itself dynamically allocated:
|
136 |
|
|
|
137 |
|
|
@smallexample
|
138 |
|
|
struct obstack *myobstack_ptr
|
139 |
|
|
= (struct obstack *) xmalloc (sizeof (struct obstack));
|
140 |
|
|
|
141 |
|
|
obstack_init (myobstack_ptr);
|
142 |
|
|
@end smallexample
|
143 |
|
|
|
144 |
|
|
@comment obstack.h
|
145 |
|
|
@comment GNU
|
146 |
|
|
@defvar obstack_alloc_failed_handler
|
147 |
|
|
The value of this variable is a pointer to a function that
|
148 |
|
|
@code{obstack} uses when @code{obstack_chunk_alloc} fails to allocate
|
149 |
|
|
memory. The default action is to print a message and abort.
|
150 |
|
|
You should supply a function that either calls @code{exit}
|
151 |
|
|
(@pxref{Program Termination, , , libc, The GNU C Library Reference Manual}) or @code{longjmp} (@pxref{Non-Local
|
152 |
|
|
Exits, , , libc, The GNU C Library Reference Manual}) and doesn't return.
|
153 |
|
|
|
154 |
|
|
@smallexample
|
155 |
|
|
void my_obstack_alloc_failed (void)
|
156 |
|
|
@dots{}
|
157 |
|
|
obstack_alloc_failed_handler = &my_obstack_alloc_failed;
|
158 |
|
|
@end smallexample
|
159 |
|
|
|
160 |
|
|
@end defvar
|
161 |
|
|
|
162 |
|
|
@node Allocation in an Obstack
|
163 |
|
|
@section Allocation in an Obstack
|
164 |
|
|
@cindex allocation (obstacks)
|
165 |
|
|
|
166 |
|
|
The most direct way to allocate an object in an obstack is with
|
167 |
|
|
@code{obstack_alloc}, which is invoked almost like @code{malloc}.
|
168 |
|
|
|
169 |
|
|
@comment obstack.h
|
170 |
|
|
@comment GNU
|
171 |
|
|
@deftypefun {void *} obstack_alloc (struct obstack *@var{obstack-ptr}, int @var{size})
|
172 |
|
|
This allocates an uninitialized block of @var{size} bytes in an obstack
|
173 |
|
|
and returns its address. Here @var{obstack-ptr} specifies which obstack
|
174 |
|
|
to allocate the block in; it is the address of the @code{struct obstack}
|
175 |
|
|
object which represents the obstack. Each obstack function or macro
|
176 |
|
|
requires you to specify an @var{obstack-ptr} as the first argument.
|
177 |
|
|
|
178 |
|
|
This function calls the obstack's @code{obstack_chunk_alloc} function if
|
179 |
|
|
it needs to allocate a new chunk of memory; it calls
|
180 |
|
|
@code{obstack_alloc_failed_handler} if allocation of memory by
|
181 |
|
|
@code{obstack_chunk_alloc} failed.
|
182 |
|
|
@end deftypefun
|
183 |
|
|
|
184 |
|
|
For example, here is a function that allocates a copy of a string @var{str}
|
185 |
|
|
in a specific obstack, which is in the variable @code{string_obstack}:
|
186 |
|
|
|
187 |
|
|
@smallexample
|
188 |
|
|
struct obstack string_obstack;
|
189 |
|
|
|
190 |
|
|
char *
|
191 |
|
|
copystring (char *string)
|
192 |
|
|
@{
|
193 |
|
|
size_t len = strlen (string) + 1;
|
194 |
|
|
char *s = (char *) obstack_alloc (&string_obstack, len);
|
195 |
|
|
memcpy (s, string, len);
|
196 |
|
|
return s;
|
197 |
|
|
@}
|
198 |
|
|
@end smallexample
|
199 |
|
|
|
200 |
|
|
To allocate a block with specified contents, use the function
|
201 |
|
|
@code{obstack_copy}, declared like this:
|
202 |
|
|
|
203 |
|
|
@comment obstack.h
|
204 |
|
|
@comment GNU
|
205 |
|
|
@deftypefun {void *} obstack_copy (struct obstack *@var{obstack-ptr}, void *@var{address}, int @var{size})
|
206 |
|
|
This allocates a block and initializes it by copying @var{size}
|
207 |
|
|
bytes of data starting at @var{address}. It calls
|
208 |
|
|
@code{obstack_alloc_failed_handler} if allocation of memory by
|
209 |
|
|
@code{obstack_chunk_alloc} failed.
|
210 |
|
|
@end deftypefun
|
211 |
|
|
|
212 |
|
|
@comment obstack.h
|
213 |
|
|
@comment GNU
|
214 |
|
|
@deftypefun {void *} obstack_copy0 (struct obstack *@var{obstack-ptr}, void *@var{address}, int @var{size})
|
215 |
|
|
Like @code{obstack_copy}, but appends an extra byte containing a null
|
216 |
|
|
character. This extra byte is not counted in the argument @var{size}.
|
217 |
|
|
@end deftypefun
|
218 |
|
|
|
219 |
|
|
The @code{obstack_copy0} function is convenient for copying a sequence
|
220 |
|
|
of characters into an obstack as a null-terminated string. Here is an
|
221 |
|
|
example of its use:
|
222 |
|
|
|
223 |
|
|
@smallexample
|
224 |
|
|
char *
|
225 |
|
|
obstack_savestring (char *addr, int size)
|
226 |
|
|
@{
|
227 |
|
|
return obstack_copy0 (&myobstack, addr, size);
|
228 |
|
|
@}
|
229 |
|
|
@end smallexample
|
230 |
|
|
|
231 |
|
|
@noindent
|
232 |
|
|
Contrast this with the previous example of @code{savestring} using
|
233 |
|
|
@code{malloc} (@pxref{Basic Allocation, , , libc, The GNU C Library Reference Manual}).
|
234 |
|
|
|
235 |
|
|
@node Freeing Obstack Objects
|
236 |
|
|
@section Freeing Objects in an Obstack
|
237 |
|
|
@cindex freeing (obstacks)
|
238 |
|
|
|
239 |
|
|
To free an object allocated in an obstack, use the function
|
240 |
|
|
@code{obstack_free}. Since the obstack is a stack of objects, freeing
|
241 |
|
|
one object automatically frees all other objects allocated more recently
|
242 |
|
|
in the same obstack.
|
243 |
|
|
|
244 |
|
|
@comment obstack.h
|
245 |
|
|
@comment GNU
|
246 |
|
|
@deftypefun void obstack_free (struct obstack *@var{obstack-ptr}, void *@var{object})
|
247 |
|
|
If @var{object} is a null pointer, everything allocated in the obstack
|
248 |
|
|
is freed. Otherwise, @var{object} must be the address of an object
|
249 |
|
|
allocated in the obstack. Then @var{object} is freed, along with
|
250 |
|
|
everything allocated in @var{obstack} since @var{object}.
|
251 |
|
|
@end deftypefun
|
252 |
|
|
|
253 |
|
|
Note that if @var{object} is a null pointer, the result is an
|
254 |
|
|
uninitialized obstack. To free all memory in an obstack but leave it
|
255 |
|
|
valid for further allocation, call @code{obstack_free} with the address
|
256 |
|
|
of the first object allocated on the obstack:
|
257 |
|
|
|
258 |
|
|
@smallexample
|
259 |
|
|
obstack_free (obstack_ptr, first_object_allocated_ptr);
|
260 |
|
|
@end smallexample
|
261 |
|
|
|
262 |
|
|
Recall that the objects in an obstack are grouped into chunks. When all
|
263 |
|
|
the objects in a chunk become free, the obstack library automatically
|
264 |
|
|
frees the chunk (@pxref{Preparing for Obstacks}). Then other
|
265 |
|
|
obstacks, or non-obstack allocation, can reuse the space of the chunk.
|
266 |
|
|
|
267 |
|
|
@node Obstack Functions
|
268 |
|
|
@section Obstack Functions and Macros
|
269 |
|
|
@cindex macros
|
270 |
|
|
|
271 |
|
|
The interfaces for using obstacks may be defined either as functions or
|
272 |
|
|
as macros, depending on the compiler. The obstack facility works with
|
273 |
|
|
all C compilers, including both @w{ISO C} and traditional C, but there are
|
274 |
|
|
precautions you must take if you plan to use compilers other than GNU C.
|
275 |
|
|
|
276 |
|
|
If you are using an old-fashioned @w{non-ISO C} compiler, all the obstack
|
277 |
|
|
``functions'' are actually defined only as macros. You can call these
|
278 |
|
|
macros like functions, but you cannot use them in any other way (for
|
279 |
|
|
example, you cannot take their address).
|
280 |
|
|
|
281 |
|
|
Calling the macros requires a special precaution: namely, the first
|
282 |
|
|
operand (the obstack pointer) may not contain any side effects, because
|
283 |
|
|
it may be computed more than once. For example, if you write this:
|
284 |
|
|
|
285 |
|
|
@smallexample
|
286 |
|
|
obstack_alloc (get_obstack (), 4);
|
287 |
|
|
@end smallexample
|
288 |
|
|
|
289 |
|
|
@noindent
|
290 |
|
|
you will find that @code{get_obstack} may be called several times.
|
291 |
|
|
If you use @code{*obstack_list_ptr++} as the obstack pointer argument,
|
292 |
|
|
you will get very strange results since the incrementation may occur
|
293 |
|
|
several times.
|
294 |
|
|
|
295 |
|
|
In @w{ISO C}, each function has both a macro definition and a function
|
296 |
|
|
definition. The function definition is used if you take the address of the
|
297 |
|
|
function without calling it. An ordinary call uses the macro definition by
|
298 |
|
|
default, but you can request the function definition instead by writing the
|
299 |
|
|
function name in parentheses, as shown here:
|
300 |
|
|
|
301 |
|
|
@smallexample
|
302 |
|
|
char *x;
|
303 |
|
|
void *(*funcp) ();
|
304 |
|
|
/* @r{Use the macro}. */
|
305 |
|
|
x = (char *) obstack_alloc (obptr, size);
|
306 |
|
|
/* @r{Call the function}. */
|
307 |
|
|
x = (char *) (obstack_alloc) (obptr, size);
|
308 |
|
|
/* @r{Take the address of the function}. */
|
309 |
|
|
funcp = obstack_alloc;
|
310 |
|
|
@end smallexample
|
311 |
|
|
|
312 |
|
|
@noindent
|
313 |
|
|
This is the same situation that exists in @w{ISO C} for the standard library
|
314 |
|
|
functions. @xref{Macro Definitions, , , libc, The GNU C Library Reference Manual}.
|
315 |
|
|
|
316 |
|
|
@strong{Warning:} When you do use the macros, you must observe the
|
317 |
|
|
precaution of avoiding side effects in the first operand, even in @w{ISO C}.
|
318 |
|
|
|
319 |
|
|
If you use the GNU C compiler, this precaution is not necessary, because
|
320 |
|
|
various language extensions in GNU C permit defining the macros so as to
|
321 |
|
|
compute each argument only once.
|
322 |
|
|
|
323 |
|
|
@node Growing Objects
|
324 |
|
|
@section Growing Objects
|
325 |
|
|
@cindex growing objects (in obstacks)
|
326 |
|
|
@cindex changing the size of a block (obstacks)
|
327 |
|
|
|
328 |
|
|
Because memory in obstack chunks is used sequentially, it is possible to
|
329 |
|
|
build up an object step by step, adding one or more bytes at a time to the
|
330 |
|
|
end of the object. With this technique, you do not need to know how much
|
331 |
|
|
data you will put in the object until you come to the end of it. We call
|
332 |
|
|
this the technique of @dfn{growing objects}. The special functions
|
333 |
|
|
for adding data to the growing object are described in this section.
|
334 |
|
|
|
335 |
|
|
You don't need to do anything special when you start to grow an object.
|
336 |
|
|
Using one of the functions to add data to the object automatically
|
337 |
|
|
starts it. However, it is necessary to say explicitly when the object is
|
338 |
|
|
finished. This is done with the function @code{obstack_finish}.
|
339 |
|
|
|
340 |
|
|
The actual address of the object thus built up is not known until the
|
341 |
|
|
object is finished. Until then, it always remains possible that you will
|
342 |
|
|
add so much data that the object must be copied into a new chunk.
|
343 |
|
|
|
344 |
|
|
While the obstack is in use for a growing object, you cannot use it for
|
345 |
|
|
ordinary allocation of another object. If you try to do so, the space
|
346 |
|
|
already added to the growing object will become part of the other object.
|
347 |
|
|
|
348 |
|
|
@comment obstack.h
|
349 |
|
|
@comment GNU
|
350 |
|
|
@deftypefun void obstack_blank (struct obstack *@var{obstack-ptr}, int @var{size})
|
351 |
|
|
The most basic function for adding to a growing object is
|
352 |
|
|
@code{obstack_blank}, which adds space without initializing it.
|
353 |
|
|
@end deftypefun
|
354 |
|
|
|
355 |
|
|
@comment obstack.h
|
356 |
|
|
@comment GNU
|
357 |
|
|
@deftypefun void obstack_grow (struct obstack *@var{obstack-ptr}, void *@var{data}, int @var{size})
|
358 |
|
|
To add a block of initialized space, use @code{obstack_grow}, which is
|
359 |
|
|
the growing-object analogue of @code{obstack_copy}. It adds @var{size}
|
360 |
|
|
bytes of data to the growing object, copying the contents from
|
361 |
|
|
@var{data}.
|
362 |
|
|
@end deftypefun
|
363 |
|
|
|
364 |
|
|
@comment obstack.h
|
365 |
|
|
@comment GNU
|
366 |
|
|
@deftypefun void obstack_grow0 (struct obstack *@var{obstack-ptr}, void *@var{data}, int @var{size})
|
367 |
|
|
This is the growing-object analogue of @code{obstack_copy0}. It adds
|
368 |
|
|
@var{size} bytes copied from @var{data}, followed by an additional null
|
369 |
|
|
character.
|
370 |
|
|
@end deftypefun
|
371 |
|
|
|
372 |
|
|
@comment obstack.h
|
373 |
|
|
@comment GNU
|
374 |
|
|
@deftypefun void obstack_1grow (struct obstack *@var{obstack-ptr}, char @var{c})
|
375 |
|
|
To add one character at a time, use the function @code{obstack_1grow}.
|
376 |
|
|
It adds a single byte containing @var{c} to the growing object.
|
377 |
|
|
@end deftypefun
|
378 |
|
|
|
379 |
|
|
@comment obstack.h
|
380 |
|
|
@comment GNU
|
381 |
|
|
@deftypefun void obstack_ptr_grow (struct obstack *@var{obstack-ptr}, void *@var{data})
|
382 |
|
|
Adding the value of a pointer one can use the function
|
383 |
|
|
@code{obstack_ptr_grow}. It adds @code{sizeof (void *)} bytes
|
384 |
|
|
containing the value of @var{data}.
|
385 |
|
|
@end deftypefun
|
386 |
|
|
|
387 |
|
|
@comment obstack.h
|
388 |
|
|
@comment GNU
|
389 |
|
|
@deftypefun void obstack_int_grow (struct obstack *@var{obstack-ptr}, int @var{data})
|
390 |
|
|
A single value of type @code{int} can be added by using the
|
391 |
|
|
@code{obstack_int_grow} function. It adds @code{sizeof (int)} bytes to
|
392 |
|
|
the growing object and initializes them with the value of @var{data}.
|
393 |
|
|
@end deftypefun
|
394 |
|
|
|
395 |
|
|
@comment obstack.h
|
396 |
|
|
@comment GNU
|
397 |
|
|
@deftypefun {void *} obstack_finish (struct obstack *@var{obstack-ptr})
|
398 |
|
|
When you are finished growing the object, use the function
|
399 |
|
|
@code{obstack_finish} to close it off and return its final address.
|
400 |
|
|
|
401 |
|
|
Once you have finished the object, the obstack is available for ordinary
|
402 |
|
|
allocation or for growing another object.
|
403 |
|
|
|
404 |
|
|
This function can return a null pointer under the same conditions as
|
405 |
|
|
@code{obstack_alloc} (@pxref{Allocation in an Obstack}).
|
406 |
|
|
@end deftypefun
|
407 |
|
|
|
408 |
|
|
When you build an object by growing it, you will probably need to know
|
409 |
|
|
afterward how long it became. You need not keep track of this as you grow
|
410 |
|
|
the object, because you can find out the length from the obstack just
|
411 |
|
|
before finishing the object with the function @code{obstack_object_size},
|
412 |
|
|
declared as follows:
|
413 |
|
|
|
414 |
|
|
@comment obstack.h
|
415 |
|
|
@comment GNU
|
416 |
|
|
@deftypefun int obstack_object_size (struct obstack *@var{obstack-ptr})
|
417 |
|
|
This function returns the current size of the growing object, in bytes.
|
418 |
|
|
Remember to call this function @emph{before} finishing the object.
|
419 |
|
|
After it is finished, @code{obstack_object_size} will return zero.
|
420 |
|
|
@end deftypefun
|
421 |
|
|
|
422 |
|
|
If you have started growing an object and wish to cancel it, you should
|
423 |
|
|
finish it and then free it, like this:
|
424 |
|
|
|
425 |
|
|
@smallexample
|
426 |
|
|
obstack_free (obstack_ptr, obstack_finish (obstack_ptr));
|
427 |
|
|
@end smallexample
|
428 |
|
|
|
429 |
|
|
@noindent
|
430 |
|
|
This has no effect if no object was growing.
|
431 |
|
|
|
432 |
|
|
@cindex shrinking objects
|
433 |
|
|
You can use @code{obstack_blank} with a negative size argument to make
|
434 |
|
|
the current object smaller. Just don't try to shrink it beyond zero
|
435 |
|
|
length---there's no telling what will happen if you do that.
|
436 |
|
|
|
437 |
|
|
@node Extra Fast Growing
|
438 |
|
|
@section Extra Fast Growing Objects
|
439 |
|
|
@cindex efficiency and obstacks
|
440 |
|
|
|
441 |
|
|
The usual functions for growing objects incur overhead for checking
|
442 |
|
|
whether there is room for the new growth in the current chunk. If you
|
443 |
|
|
are frequently constructing objects in small steps of growth, this
|
444 |
|
|
overhead can be significant.
|
445 |
|
|
|
446 |
|
|
You can reduce the overhead by using special ``fast growth''
|
447 |
|
|
functions that grow the object without checking. In order to have a
|
448 |
|
|
robust program, you must do the checking yourself. If you do this checking
|
449 |
|
|
in the simplest way each time you are about to add data to the object, you
|
450 |
|
|
have not saved anything, because that is what the ordinary growth
|
451 |
|
|
functions do. But if you can arrange to check less often, or check
|
452 |
|
|
more efficiently, then you make the program faster.
|
453 |
|
|
|
454 |
|
|
The function @code{obstack_room} returns the amount of room available
|
455 |
|
|
in the current chunk. It is declared as follows:
|
456 |
|
|
|
457 |
|
|
@comment obstack.h
|
458 |
|
|
@comment GNU
|
459 |
|
|
@deftypefun int obstack_room (struct obstack *@var{obstack-ptr})
|
460 |
|
|
This returns the number of bytes that can be added safely to the current
|
461 |
|
|
growing object (or to an object about to be started) in obstack
|
462 |
|
|
@var{obstack} using the fast growth functions.
|
463 |
|
|
@end deftypefun
|
464 |
|
|
|
465 |
|
|
While you know there is room, you can use these fast growth functions
|
466 |
|
|
for adding data to a growing object:
|
467 |
|
|
|
468 |
|
|
@comment obstack.h
|
469 |
|
|
@comment GNU
|
470 |
|
|
@deftypefun void obstack_1grow_fast (struct obstack *@var{obstack-ptr}, char @var{c})
|
471 |
|
|
The function @code{obstack_1grow_fast} adds one byte containing the
|
472 |
|
|
character @var{c} to the growing object in obstack @var{obstack-ptr}.
|
473 |
|
|
@end deftypefun
|
474 |
|
|
|
475 |
|
|
@comment obstack.h
|
476 |
|
|
@comment GNU
|
477 |
|
|
@deftypefun void obstack_ptr_grow_fast (struct obstack *@var{obstack-ptr}, void *@var{data})
|
478 |
|
|
The function @code{obstack_ptr_grow_fast} adds @code{sizeof (void *)}
|
479 |
|
|
bytes containing the value of @var{data} to the growing object in
|
480 |
|
|
obstack @var{obstack-ptr}.
|
481 |
|
|
@end deftypefun
|
482 |
|
|
|
483 |
|
|
@comment obstack.h
|
484 |
|
|
@comment GNU
|
485 |
|
|
@deftypefun void obstack_int_grow_fast (struct obstack *@var{obstack-ptr}, int @var{data})
|
486 |
|
|
The function @code{obstack_int_grow_fast} adds @code{sizeof (int)} bytes
|
487 |
|
|
containing the value of @var{data} to the growing object in obstack
|
488 |
|
|
@var{obstack-ptr}.
|
489 |
|
|
@end deftypefun
|
490 |
|
|
|
491 |
|
|
@comment obstack.h
|
492 |
|
|
@comment GNU
|
493 |
|
|
@deftypefun void obstack_blank_fast (struct obstack *@var{obstack-ptr}, int @var{size})
|
494 |
|
|
The function @code{obstack_blank_fast} adds @var{size} bytes to the
|
495 |
|
|
growing object in obstack @var{obstack-ptr} without initializing them.
|
496 |
|
|
@end deftypefun
|
497 |
|
|
|
498 |
|
|
When you check for space using @code{obstack_room} and there is not
|
499 |
|
|
enough room for what you want to add, the fast growth functions
|
500 |
|
|
are not safe. In this case, simply use the corresponding ordinary
|
501 |
|
|
growth function instead. Very soon this will copy the object to a
|
502 |
|
|
new chunk; then there will be lots of room available again.
|
503 |
|
|
|
504 |
|
|
So, each time you use an ordinary growth function, check afterward for
|
505 |
|
|
sufficient space using @code{obstack_room}. Once the object is copied
|
506 |
|
|
to a new chunk, there will be plenty of space again, so the program will
|
507 |
|
|
start using the fast growth functions again.
|
508 |
|
|
|
509 |
|
|
Here is an example:
|
510 |
|
|
|
511 |
|
|
@smallexample
|
512 |
|
|
@group
|
513 |
|
|
void
|
514 |
|
|
add_string (struct obstack *obstack, const char *ptr, int len)
|
515 |
|
|
@{
|
516 |
|
|
while (len > 0)
|
517 |
|
|
@{
|
518 |
|
|
int room = obstack_room (obstack);
|
519 |
|
|
if (room == 0)
|
520 |
|
|
@{
|
521 |
|
|
/* @r{Not enough room. Add one character slowly,}
|
522 |
|
|
@r{which may copy to a new chunk and make room.} */
|
523 |
|
|
obstack_1grow (obstack, *ptr++);
|
524 |
|
|
len--;
|
525 |
|
|
@}
|
526 |
|
|
else
|
527 |
|
|
@{
|
528 |
|
|
if (room > len)
|
529 |
|
|
room = len;
|
530 |
|
|
/* @r{Add fast as much as we have room for.} */
|
531 |
|
|
len -= room;
|
532 |
|
|
while (room-- > 0)
|
533 |
|
|
obstack_1grow_fast (obstack, *ptr++);
|
534 |
|
|
@}
|
535 |
|
|
@}
|
536 |
|
|
@}
|
537 |
|
|
@end group
|
538 |
|
|
@end smallexample
|
539 |
|
|
|
540 |
|
|
@node Status of an Obstack
|
541 |
|
|
@section Status of an Obstack
|
542 |
|
|
@cindex obstack status
|
543 |
|
|
@cindex status of obstack
|
544 |
|
|
|
545 |
|
|
Here are functions that provide information on the current status of
|
546 |
|
|
allocation in an obstack. You can use them to learn about an object while
|
547 |
|
|
still growing it.
|
548 |
|
|
|
549 |
|
|
@comment obstack.h
|
550 |
|
|
@comment GNU
|
551 |
|
|
@deftypefun {void *} obstack_base (struct obstack *@var{obstack-ptr})
|
552 |
|
|
This function returns the tentative address of the beginning of the
|
553 |
|
|
currently growing object in @var{obstack-ptr}. If you finish the object
|
554 |
|
|
immediately, it will have that address. If you make it larger first, it
|
555 |
|
|
may outgrow the current chunk---then its address will change!
|
556 |
|
|
|
557 |
|
|
If no object is growing, this value says where the next object you
|
558 |
|
|
allocate will start (once again assuming it fits in the current
|
559 |
|
|
chunk).
|
560 |
|
|
@end deftypefun
|
561 |
|
|
|
562 |
|
|
@comment obstack.h
|
563 |
|
|
@comment GNU
|
564 |
|
|
@deftypefun {void *} obstack_next_free (struct obstack *@var{obstack-ptr})
|
565 |
|
|
This function returns the address of the first free byte in the current
|
566 |
|
|
chunk of obstack @var{obstack-ptr}. This is the end of the currently
|
567 |
|
|
growing object. If no object is growing, @code{obstack_next_free}
|
568 |
|
|
returns the same value as @code{obstack_base}.
|
569 |
|
|
@end deftypefun
|
570 |
|
|
|
571 |
|
|
@comment obstack.h
|
572 |
|
|
@comment GNU
|
573 |
|
|
@deftypefun int obstack_object_size (struct obstack *@var{obstack-ptr})
|
574 |
|
|
This function returns the size in bytes of the currently growing object.
|
575 |
|
|
This is equivalent to
|
576 |
|
|
|
577 |
|
|
@smallexample
|
578 |
|
|
obstack_next_free (@var{obstack-ptr}) - obstack_base (@var{obstack-ptr})
|
579 |
|
|
@end smallexample
|
580 |
|
|
@end deftypefun
|
581 |
|
|
|
582 |
|
|
@node Obstacks Data Alignment
|
583 |
|
|
@section Alignment of Data in Obstacks
|
584 |
|
|
@cindex alignment (in obstacks)
|
585 |
|
|
|
586 |
|
|
Each obstack has an @dfn{alignment boundary}; each object allocated in
|
587 |
|
|
the obstack automatically starts on an address that is a multiple of the
|
588 |
|
|
specified boundary. By default, this boundary is 4 bytes.
|
589 |
|
|
|
590 |
|
|
To access an obstack's alignment boundary, use the macro
|
591 |
|
|
@code{obstack_alignment_mask}, whose function prototype looks like
|
592 |
|
|
this:
|
593 |
|
|
|
594 |
|
|
@comment obstack.h
|
595 |
|
|
@comment GNU
|
596 |
|
|
@deftypefn Macro int obstack_alignment_mask (struct obstack *@var{obstack-ptr})
|
597 |
|
|
The value is a bit mask; a bit that is 1 indicates that the corresponding
|
598 |
|
|
bit in the address of an object should be 0. The mask value should be one
|
599 |
|
|
less than a power of 2; the effect is that all object addresses are
|
600 |
|
|
multiples of that power of 2. The default value of the mask is 3, so that
|
601 |
|
|
addresses are multiples of 4. A mask value of 0 means an object can start
|
602 |
|
|
on any multiple of 1 (that is, no alignment is required).
|
603 |
|
|
|
604 |
|
|
The expansion of the macro @code{obstack_alignment_mask} is an lvalue,
|
605 |
|
|
so you can alter the mask by assignment. For example, this statement:
|
606 |
|
|
|
607 |
|
|
@smallexample
|
608 |
|
|
obstack_alignment_mask (obstack_ptr) = 0;
|
609 |
|
|
@end smallexample
|
610 |
|
|
|
611 |
|
|
@noindent
|
612 |
|
|
has the effect of turning off alignment processing in the specified obstack.
|
613 |
|
|
@end deftypefn
|
614 |
|
|
|
615 |
|
|
Note that a change in alignment mask does not take effect until
|
616 |
|
|
@emph{after} the next time an object is allocated or finished in the
|
617 |
|
|
obstack. If you are not growing an object, you can make the new
|
618 |
|
|
alignment mask take effect immediately by calling @code{obstack_finish}.
|
619 |
|
|
This will finish a zero-length object and then do proper alignment for
|
620 |
|
|
the next object.
|
621 |
|
|
|
622 |
|
|
@node Obstack Chunks
|
623 |
|
|
@section Obstack Chunks
|
624 |
|
|
@cindex efficiency of chunks
|
625 |
|
|
@cindex chunks
|
626 |
|
|
|
627 |
|
|
Obstacks work by allocating space for themselves in large chunks, and
|
628 |
|
|
then parceling out space in the chunks to satisfy your requests. Chunks
|
629 |
|
|
are normally 4096 bytes long unless you specify a different chunk size.
|
630 |
|
|
The chunk size includes 8 bytes of overhead that are not actually used
|
631 |
|
|
for storing objects. Regardless of the specified size, longer chunks
|
632 |
|
|
will be allocated when necessary for long objects.
|
633 |
|
|
|
634 |
|
|
The obstack library allocates chunks by calling the function
|
635 |
|
|
@code{obstack_chunk_alloc}, which you must define. When a chunk is no
|
636 |
|
|
longer needed because you have freed all the objects in it, the obstack
|
637 |
|
|
library frees the chunk by calling @code{obstack_chunk_free}, which you
|
638 |
|
|
must also define.
|
639 |
|
|
|
640 |
|
|
These two must be defined (as macros) or declared (as functions) in each
|
641 |
|
|
source file that uses @code{obstack_init} (@pxref{Creating Obstacks}).
|
642 |
|
|
Most often they are defined as macros like this:
|
643 |
|
|
|
644 |
|
|
@smallexample
|
645 |
|
|
#define obstack_chunk_alloc malloc
|
646 |
|
|
#define obstack_chunk_free free
|
647 |
|
|
@end smallexample
|
648 |
|
|
|
649 |
|
|
Note that these are simple macros (no arguments). Macro definitions with
|
650 |
|
|
arguments will not work! It is necessary that @code{obstack_chunk_alloc}
|
651 |
|
|
or @code{obstack_chunk_free}, alone, expand into a function name if it is
|
652 |
|
|
not itself a function name.
|
653 |
|
|
|
654 |
|
|
If you allocate chunks with @code{malloc}, the chunk size should be a
|
655 |
|
|
power of 2. The default chunk size, 4096, was chosen because it is long
|
656 |
|
|
enough to satisfy many typical requests on the obstack yet short enough
|
657 |
|
|
not to waste too much memory in the portion of the last chunk not yet used.
|
658 |
|
|
|
659 |
|
|
@comment obstack.h
|
660 |
|
|
@comment GNU
|
661 |
|
|
@deftypefn Macro int obstack_chunk_size (struct obstack *@var{obstack-ptr})
|
662 |
|
|
This returns the chunk size of the given obstack.
|
663 |
|
|
@end deftypefn
|
664 |
|
|
|
665 |
|
|
Since this macro expands to an lvalue, you can specify a new chunk size by
|
666 |
|
|
assigning it a new value. Doing so does not affect the chunks already
|
667 |
|
|
allocated, but will change the size of chunks allocated for that particular
|
668 |
|
|
obstack in the future. It is unlikely to be useful to make the chunk size
|
669 |
|
|
smaller, but making it larger might improve efficiency if you are
|
670 |
|
|
allocating many objects whose size is comparable to the chunk size. Here
|
671 |
|
|
is how to do so cleanly:
|
672 |
|
|
|
673 |
|
|
@smallexample
|
674 |
|
|
if (obstack_chunk_size (obstack_ptr) < @var{new-chunk-size})
|
675 |
|
|
obstack_chunk_size (obstack_ptr) = @var{new-chunk-size};
|
676 |
|
|
@end smallexample
|
677 |
|
|
|
678 |
|
|
@node Summary of Obstacks
|
679 |
|
|
@section Summary of Obstack Functions
|
680 |
|
|
|
681 |
|
|
Here is a summary of all the functions associated with obstacks. Each
|
682 |
|
|
takes the address of an obstack (@code{struct obstack *}) as its first
|
683 |
|
|
argument.
|
684 |
|
|
|
685 |
|
|
@table @code
|
686 |
|
|
@item void obstack_init (struct obstack *@var{obstack-ptr})
|
687 |
|
|
Initialize use of an obstack. @xref{Creating Obstacks}.
|
688 |
|
|
|
689 |
|
|
@item void *obstack_alloc (struct obstack *@var{obstack-ptr}, int @var{size})
|
690 |
|
|
Allocate an object of @var{size} uninitialized bytes.
|
691 |
|
|
@xref{Allocation in an Obstack}.
|
692 |
|
|
|
693 |
|
|
@item void *obstack_copy (struct obstack *@var{obstack-ptr}, void *@var{address}, int @var{size})
|
694 |
|
|
Allocate an object of @var{size} bytes, with contents copied from
|
695 |
|
|
@var{address}. @xref{Allocation in an Obstack}.
|
696 |
|
|
|
697 |
|
|
@item void *obstack_copy0 (struct obstack *@var{obstack-ptr}, void *@var{address}, int @var{size})
|
698 |
|
|
Allocate an object of @var{size}+1 bytes, with @var{size} of them copied
|
699 |
|
|
from @var{address}, followed by a null character at the end.
|
700 |
|
|
@xref{Allocation in an Obstack}.
|
701 |
|
|
|
702 |
|
|
@item void obstack_free (struct obstack *@var{obstack-ptr}, void *@var{object})
|
703 |
|
|
Free @var{object} (and everything allocated in the specified obstack
|
704 |
|
|
more recently than @var{object}). @xref{Freeing Obstack Objects}.
|
705 |
|
|
|
706 |
|
|
@item void obstack_blank (struct obstack *@var{obstack-ptr}, int @var{size})
|
707 |
|
|
Add @var{size} uninitialized bytes to a growing object.
|
708 |
|
|
@xref{Growing Objects}.
|
709 |
|
|
|
710 |
|
|
@item void obstack_grow (struct obstack *@var{obstack-ptr}, void *@var{address}, int @var{size})
|
711 |
|
|
Add @var{size} bytes, copied from @var{address}, to a growing object.
|
712 |
|
|
@xref{Growing Objects}.
|
713 |
|
|
|
714 |
|
|
@item void obstack_grow0 (struct obstack *@var{obstack-ptr}, void *@var{address}, int @var{size})
|
715 |
|
|
Add @var{size} bytes, copied from @var{address}, to a growing object,
|
716 |
|
|
and then add another byte containing a null character. @xref{Growing
|
717 |
|
|
Objects}.
|
718 |
|
|
|
719 |
|
|
@item void obstack_1grow (struct obstack *@var{obstack-ptr}, char @var{data-char})
|
720 |
|
|
Add one byte containing @var{data-char} to a growing object.
|
721 |
|
|
@xref{Growing Objects}.
|
722 |
|
|
|
723 |
|
|
@item void *obstack_finish (struct obstack *@var{obstack-ptr})
|
724 |
|
|
Finalize the object that is growing and return its permanent address.
|
725 |
|
|
@xref{Growing Objects}.
|
726 |
|
|
|
727 |
|
|
@item int obstack_object_size (struct obstack *@var{obstack-ptr})
|
728 |
|
|
Get the current size of the currently growing object. @xref{Growing
|
729 |
|
|
Objects}.
|
730 |
|
|
|
731 |
|
|
@item void obstack_blank_fast (struct obstack *@var{obstack-ptr}, int @var{size})
|
732 |
|
|
Add @var{size} uninitialized bytes to a growing object without checking
|
733 |
|
|
that there is enough room. @xref{Extra Fast Growing}.
|
734 |
|
|
|
735 |
|
|
@item void obstack_1grow_fast (struct obstack *@var{obstack-ptr}, char @var{data-char})
|
736 |
|
|
Add one byte containing @var{data-char} to a growing object without
|
737 |
|
|
checking that there is enough room. @xref{Extra Fast Growing}.
|
738 |
|
|
|
739 |
|
|
@item int obstack_room (struct obstack *@var{obstack-ptr})
|
740 |
|
|
Get the amount of room now available for growing the current object.
|
741 |
|
|
@xref{Extra Fast Growing}.
|
742 |
|
|
|
743 |
|
|
@item int obstack_alignment_mask (struct obstack *@var{obstack-ptr})
|
744 |
|
|
The mask used for aligning the beginning of an object. This is an
|
745 |
|
|
lvalue. @xref{Obstacks Data Alignment}.
|
746 |
|
|
|
747 |
|
|
@item int obstack_chunk_size (struct obstack *@var{obstack-ptr})
|
748 |
|
|
The size for allocating chunks. This is an lvalue. @xref{Obstack Chunks}.
|
749 |
|
|
|
750 |
|
|
@item void *obstack_base (struct obstack *@var{obstack-ptr})
|
751 |
|
|
Tentative starting address of the currently growing object.
|
752 |
|
|
@xref{Status of an Obstack}.
|
753 |
|
|
|
754 |
|
|
@item void *obstack_next_free (struct obstack *@var{obstack-ptr})
|
755 |
|
|
Address just after the end of the currently growing object.
|
756 |
|
|
@xref{Status of an Obstack}.
|
757 |
|
|
@end table
|
758 |
|
|
|