-<!-- $Id: odr.xml,v 1.3 2001-07-20 21:34:36 adam Exp $ -->
+<!-- $Id: odr.xml,v 1.4 2001-08-13 09:42:54 adam Exp $ -->
<chapter><title id="odr">The ODR Module</title>
<sect1><title>Introduction</title>
small bits of space, the system maintains a freelist of larger chunks
of memory, which are handed out in small bits. This scheme is
generally known as a <emphasis>nibble memory</emphasis> system.
- It is very useful for maintaing short-lived constructions such
+ It is very useful for maintaining short-lived constructions such
as protocol PDUs.
</para>
The integer pointed to by len is set to the length of the encoded
data, and a pointer to that data is returned. <literal>*size</literal>
is set to the size of the buffer (unless <literal>size</literal> is null,
- signalling that you are not interested in the size). The next call to
+ signaling that you are not interested in the size). The next call to
a primitive function using the same &odr; stream will overwrite the
data, unless a different buffer has been supplied using the call
</para>
</para>
<para>
- It is important to realise that the ODR stream will not release this
+ It is important to realize that the ODR stream will not release this
memory when you call <function>odr_reset()</function>: It will
merely update its internal pointers to prepare for the encoding of a
new data value.
be released <emphasis>only</emphasis> if the <literal>can_grow</literal>
parameter to <function>odr_setbuf()</function> was nonzero. The
<literal>can_grow</literal> parameter, in other words, is a way of
- signalling who is to own the buffer, you or the ODR stream. If you never call
+ signaling who is to own the buffer, you or the ODR stream. If you never call
<function>odr_setbuf()</function> on your encoding stream, which is
typically the case, the buffer allocated by the stream will belong to
the stream by default.
type has a dual function. Depending on the settings of the ODR
stream which is supplied as a parameter, the function may be used
either to encode or decode data. The functions that can be built
- using these primitive functions, to represent more complex datatypes, share
+ using these primitive functions, to represent more complex data types, share
this quality. The result is that you only have to enter the definition
for a type once - and you have the functionality of encoding, decoding
(and pretty-printing) all in one unit. The resulting C source code is
In many cases, the model of the XDR functions works quite well in this
role.
In others, it is less elegant. Most of the hassle comes from the optional
- SEQUENCE memebers which don't exist in XDR.
+ SEQUENCE members which don't exist in XDR.
</para>
<sect2><title>The Primitive ASN.1 Types</title>
</synopsis>
<para>
- The C OID represenation is simply an array of integers, terminated by
+ The C OID representation is simply an array of integers, terminated by
the value -1 (the <literal>Odr_oid</literal> type is synonymous with
the <literal>int</literal> type).
We suggest that you use the OID database module (see section
You could, of course, name your structures, types, and functions any way
you please - as long as you're consistent, and your code is easily readable.
<literal>odr_ok</literal> is just that - a predicate that returns the
- state of the stream. It is used to ensure that the behaviour of the new
+ state of the stream. It is used to ensure that the behavior of the new
type is compatible with the interface of the primitive types.
</para>
Notice that the interface here gets kind of nasty. The reason is
simple: Explicitly tagged, constructed types are fairly rare in
the protocols that we care about, so the
- aesthetic annoyance (not to mention the dangers of a cluttered
+ esthetic annoyance (not to mention the dangers of a cluttered
interface) is less than the time that would be required to develop a
better interface. Nevertheless, it is far from satisfying, and it's a
point that will be worked on in the future. One option for you would
<sect2><title>SEQUENCE OF</title>
<para>
- To handle sequences (arrays) of a apecific type, the function
+ To handle sequences (arrays) of a specific type, the function
</para>
<synopsis>
</para>
<para>
- The ASN.1 specifictions naturally requires that each member of a
+ The ASN.1 specifications naturally requires that each member of a
CHOICE have a distinct tag, so they can be told apart on decoding.
Sometimes it can be useful to define a CHOICE that has multiple types
that share the same tag. You'll need some other mechanism, perhaps
projects / yaz-moved-to-github.git / blobdiff