*** /dev/null Mon Apr 29 01:55:00 2024
--- - Mon Apr 29 01:57:43 2024
***************
*** 0 ****
--- 1,620 ----
+ ##
+ ## OSSP xds - Extensible Data Serialization
+ ## Copyright (c) 2001-2005 Ralf S. Engelschall <rse@engelschall.com>
+ ## Copyright (c) 2001-2005 The OSSP Project <http://www.ossp.org/>
+ ## Copyright (c) 2001-2005 Cable & Wireless <http://www.cw.com/>
+ ##
+ ## This file is part of OSSP xds, an extensible data serialization
+ ## library which can be found at http://www.ossp.org/pkg/lib/xds/.
+ ##
+ ## Permission to use, copy, modify, and distribute this software for
+ ## any purpose with or without fee is hereby granted, provided that
+ ## the above copyright notice and this permission notice appear in all
+ ## copies.
+ ##
+ ## THIS SOFTWARE IS PROVIDED `AS IS' AND ANY EXPRESSED OR IMPLIED
+ ## WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ ## MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ ## IN NO EVENT SHALL THE AUTHORS AND COPYRIGHT HOLDERS AND THEIR
+ ## CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ ## SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ ## LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ ## USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ ## ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ ## OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+ ## OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ ## SUCH DAMAGE.
+ ##
+ ## xds.pod: Unix manual page source
+ ##
+
+ =pod
+
+ =head1 NAME
+
+ B<OSSP xds> - eXtensible Data Serialization
+
+ =head1 SYNOPSIS
+
+ xds_init,
+ xds_destroy,
+ xds_register,
+ xds_unregister,
+ xds_setbuffer,
+ xds_getbuffer,
+ xds_encode,
+ xds_decode,
+ xds_vencode,
+ xds_vdecode.
+
+ =head1 DESCRIPTION
+
+ The B<OSSP xds> library is generic and extensible encoding and decoding
+ framework for the serialization of arbitrary ISO C data types. B<OSSP
+ xds> consists of three components: the generic encoding and decoding
+ framework, a set of shipped engines to encode and decode values in
+ certain existing formats (Sun RPC/XDR and XDS/XML are currently
+ provided), and a run-time context, which is used to manage buffers,
+ registered engines, etc. The library is designed to allow fully
+ recursive and efficient encoding/decoding of arbitrary nested data.
+
+ =head2 INTRODUCTION
+
+ In order to use B<OSSP xds>, the first thing the developer has to
+ do is to create a valid context by calling xds_init(). The function
+ requires one parameter that determines whether to operate in encoding-
+ or decoding mode. A context can be used for encoding or decoding only;
+ it is not possible to use the same context for both operations. Once a
+ valid context has been obtained, the function xds_register() can be used
+ to register an arbitrary number of encoding (or decoding) engines within
+ the context.
+
+ Two sets of engines are included in the library, additional ones can be
+ easily programmed. These functions will handle any elementary datatype
+ defined by the ISO-C language, such as 32-bit integers, 64-bit integers,
+ unsigned integers (of both 32 and 64-bit), floating point numbers,
+ strings and octet streams.
+
+ Once all required encoding/decoding engines are registered, the
+ functions xds_encode() or xds_decode() may be used to actually perform
+ the encoding or decoding process. Any data type for which an engine has
+ been registered before can be handled by the library.
+
+ This means, it is possible for the developer to write custom engines for
+ any data type he desires to use and to register them in the context --
+ as long as these engines adhere to the C<xds_engine_t> interface defined
+ in F<xds.h>.
+
+ In particular, it is possible to register meta engines. This is an
+ engine designed to encode or decode data types which consist of several
+ elementary data types. Such an engine will simply re-use the existing
+ engines to encode or decode the elements of the structure.
+
+ The following example program (without error checking for simplicity)
+ will encode the unsigned integer 0x1234 into the B<XDR> format (known from
+ Sun RPC), decode it back into the native host format, and compare the
+ result to make sure it is the original value again:
+
+ #include <stdio.h>
+ #include <errno.h>
+
+ #include "xds.h"
+
+ int main(int argc, char *argv[])
+ {
+ xds_t *xds;
+ xds_uint32_t uint32 = 0x1234;
+ xds_uint32_t uint32_new;
+ char *buffer;
+ size_t buffer_size;
+
+ /* encoding */
+ xds = xds_init(XDS_ENCODE);
+ xds_register(xds, "uint32", &xdr_encode_uint32, NULL);
+ xds_encode(xds, "uint32", uint32);
+ xds_getbuffer(xds, XDS_GIFT, (void**)&buffer, &buffer_size);
+ xds_destroy(xds);
+
+ /* ...usually buffer is now transferred to a remote system... */
+
+ /* decoding */
+ xds = xds_init(XDS_DECODE);
+ xds_register(xds, "uint32", &xdr_decode_uint32, NULL);
+ xds_setbuffer(xds, XDS_LOAN, buffer, buffer_size);
+ xds_decode(xds, "uint32", &uint32_new);
+ xds_destroy(xds);
+
+ /* comparison */
+ if (uint32 == uint32_new)
+ printf("OK\n");
+ else
+ printf("Failure\n");
+ return 0;
+ }
+
+ =head1 THE XDS FRAMEWORK
+
+ B<OSSP xds> provides a generic framework for encoding and decoding.
+ The corresponding API is described here.
+
+ =over 4
+
+ =item xds_t *B<xds_init>(xds_mode_t I<mode>);
+
+ This function creates and initializes a context. The I<mode> parameter
+ may be either C<XDS_ENCODE> or C<XDS_DECODE>, depending on whether you
+ want to encode or decode data. If successful, xds_init() returns a
+ pointer to the context. In case of failure, xds_init() returns C<NULL>
+ and sets errno to C<ENOMEM> (failed to allocate internal memory buffers)
+ or C<EINVAL> (I<mode> parameter was invalid).
+
+ A context obtained from xds_init() must be destroyed by xds_destroy() if
+ it is no longer needed.
+
+ =item void B<xds_destroy>(xds_t *I<xds>);
+
+ xds_destroy() will destroy the context I<xds>, created by xds_init().
+ Doing so will return all resources associated with this context -- most
+ notably the memory used to buffer the results of encoding or decoding
+ any values. A context may not be used after it has been destroyed.
+
+ =item int B<xds_register>(xds_t *I<xds>, const char *I<name>, xds_engine_t I<engine>, void *I<engine_context>);
+
+ This function will register an engine in the provided context. An
+ I<engine> is potentially any function that fullfils the following
+ interface:
+
+ int B<engine>(xds_t *I<xds>, void *I<engine_context>, void *I<buffer>, size_t I<buffer_size>, size_t *I<used_buffer_size>, va_list *I<args>);
+
+ By calling xds_register(), the I<engine> will be registered under the
+ name I<name> in the context I<xds>. The last parameter I<engine_context>
+ may be used as the user sees fit: It will be passed when the engine is
+ actually called and may be used to implement an engine-specific context.
+ Most engines will not need a context of their own, in which case C<NULL>
+ should be specified here.
+
+ Please note that until the user calls xds_register() for a context he
+ obtained from xds_init(), no engines are registered for that context.
+ Even the engines included in the B<OSSP xds> source distribution are not
+ registered automatically.
+
+ For engine names, any combination of the characters a-z, A-Z, 0-9, "-",
+ and "_" may be used; anything else is not a legal engine name component.
+
+ xds_register() may return the following return codes: C<XDS_OK>
+ (everything went fine; the engine is registered now),
+ C<XDS_ERR_INVALID_ARG> (either I<xds>, I<name>, or I<engine> are
+ C<NULL> or I<name> contains illegal characters for an engine name), or
+ C<XDS_ERR_NO_MEM> (failed to allocate internally required buffers).
+
+ =item int B<xds_unregister>(xds_t *I<xds>, const char *I<name>);
+
+ xds_unregister() will remove the engine I<name> from the context I<xds>.
+ The function will return C<XDS_OK> in case everything went fine,
+ C<XDS_ERR_UNKNOWN_ENGINE> in case the engine I<name> is not registered
+ in I<xds>, or C<XDS_ERR_INVALID_ARG> if either I<xds> or I<name> are
+ C<NULL> or I<name> contains illegal characters for an engine name.
+
+ =item int B<xds_setbuffer>(xds_t *I<xds>, xds_scope_t I<flag>, void *I<buffer>, size_t I<buffer_len>);
+
+ This function allows the user to control the buffer handling: Calling
+ it will replace the buffer currently used in I<xds>. The address and
+ size of that buffer are passed to xds_setbuffer() via the I<buffer> and
+ I<buffer_len> parameters. The I<xds> parameter determines for which
+ context the new buffer will be set. Furthermore, you can set I<flag> to
+ either C<XDS_GIFT> or C<XDS_LOAN>.
+
+ C<XDS_GIFT> will tell B<OSSP xds> that the provided buffer is now
+ owned by the library and that it may be resized by calling realloc(3).
+ Furthermore, the buffer is free(3)'ed when I<xds> is destroyed. If
+ I<flag> is C<XDS_GIFT> and I<buffer> is C<NULL>, xds_setbuffer() will
+ simply allocate a buffer of its own to be set in I<xds>. Please note
+ that a buffer given to the library as a gift B<must> have been allocated
+ using malloc(3) -- it may not live on the stack because B<OSSP xds> will
+ try to free or to resize the buffer as it sees fit.
+
+ Passing C<XDS_LOAN> via I<flag> tells xds_setbuffer() that the buffer is
+ owned by the application and that B<OSSP xds> should not free nor resize
+ the buffer in any case. In this mode, passing a buffer of C<NULL> will
+ result in an invalid-argument error.
+
+ =item int B<xds_getbuffer>(xds_t *I<xds>, xds_scope_t I<flag>, void **I<buffer>, size_t *I<buffer_len>);
+
+ This function is the counterpart to xds_setbuffer(): It will get
+ the buffer currently used in the context I<xds>. The address of that
+ buffer is stored in the location I<buffer> points to; the length of the
+ buffer's content will be stored in the location I<buffer_len> points to.
+
+ The I<flag> argument may be set to either C<XDS_GIFT> or C<XDS_LOAN>.
+ The first setting means that the buffer is now owned by the application
+ and that B<OSSP xds> must not use it after this xds_getbuffer() call
+ anymore; it will allocate a new internal buffer instead. Of course,
+ this also means that the buffer will not be freed by xds_destroy();
+ the application has to free(3) the buffer itself when it is not needed
+ anymore.
+
+ Setting I<flag> to C<XDS_LOAN> tells B<OSSP xds> that the application
+ just wishes to peek into the buffer and will not modify it. The buffer
+ is still owned (and used) by B<OSSP xds>. Please note that the loaned
+ address returned by xds_getbuffer() may change after any other xds_xxx()
+ function call!
+
+ The function will return C<XDS_OK> (everything went fine) or
+ C<XDS_ERR_INVALID_ARG> (I<xds>, I<buffer> or I<buffer_len> are C<NULL>
+ or I<flag> is invalid) signifying success or failure respectively.
+
+ Please note: It is perfectly legal for xds_getbuffer() to return a
+ buffer of C<NULL> and a buffer length of C<0>! This happens when
+ xds_getbuffer() is called for a fresh context before a buffer has been
+ allocated at all.
+
+ =item int B<xds_vencode>(xds_t *I<xds>, const char *I<fmt>, va_list I<args>);
+
+ This function will encode one or several values using the appropriate
+ encoding engines registered in the context I<xds>. The parameter I<fmt>
+ contains a sprintf(3)-alike descriptions of the values to be
+ encoded; the actual values are provided in the varadic parameter I<args>.
+
+ The format for I<fmt> is simple: Just provide the names of the engines to
+ be used for encoding the appropriate value(s) in I<args>. Any non-legal
+ engine-name character may be used as a delimiter. In order to encode two
+ 32-bit integers followed by a 64-bit integer, the format string
+
+ int32 int32 int64
+
+ could be used. In case you don't like the blank, use the colon instead:
+
+ int32:int32:int64
+
+ Of course the names to be used here have to match to the names used to
+ register the engines in I<xds> earlier.
+
+ Every time xds_vencode() is called, it will append the encoded data
+ at the end of the internal buffer stored in I<xds>. Thus, you can
+ call xds_vencode() several times in order to encode several values,
+ but you'll still get all encoded values stored in one buffer. Calling
+ xds_setbuffer() or xds_getbuffer() with gift semantics at any point
+ during encoding will re-set the buffer to the beginning. All values
+ that have been encoded into that buffer already will eventually be
+ overwritten when xds_encode() is called again. Hence: Don't call
+ xds_setbuffer() or xds_getbuffer() unless you actually want to access
+ the data stored in the buffer.
+
+ Also, it should be noted that the data you have to provide for I<args>
+ depends entirely on what the deployed engines expect to find on the
+ stack -- there is no "standard" on what should be put on the stack here.
+ The B<XML> and B<XDR> engines included in the distribution will simply expect
+ the value to be encoded to be found on the stack, but other engines may
+ act differently.
+
+ xds_vencode() will return any of the following return codes: C<XDS_OK>
+ (everything worked fine), C<XDS_ERR_NO_MEM> (failed to allocate or to
+ resize the internal buffer), C<XDS_ERR_OVERFLOW> (the internal buffer
+ is too small but is not owned by us), C<XDS_ERR_INVALID_ARG> (I<xds> or
+ I<fmt> are C<NULL>), C<XDS_ERR_UNKNOWN_ENGINE> (an engine name specified
+ in I<fmt> is not registered in I<xds>), C<XDS_ERR_INVALID_MODE> (I<xds>
+ is initialized in decode mode), or C<XDS_ERR_UNKNOWN> (the engine
+ returned an unspecified error).
+
+ =item int B<xds_encode>(xds_t *I<xds>, const char *I<fmt>, ...);
+
+ This function is basically identical to xds_vencode(), only that
+ it uses a different prototype syntax.
+
+ =item int B<xds_vdecode>(xds_t *I<xds>, const char *I<fmt>, va_list I<args>);
+
+ This function is almost identical to xds_vencode(): It expects a
+ context, a format string and a set of parameters for the engines, but
+ xds_vdecode() does not encode any data, it decodes the data back into
+ the native format. The format string determines which engines are to be
+ called by the framework in order to decode the values contained in the
+ buffer. The values will then be stored at the locations found in the
+ corresponding I<args> entry. But please note that the exact behavior of
+ the decoding engines is not specified! The B<XML> and B<XDR> engines included
+ in this distribution expect a pointer to a location where to store the
+ decoded value, but other engines may vary.
+
+ xds_vdecode() may return any of the following return codes: C<XDS_OK>
+ (everything went fine), C<XDS_ERR_INVALID_ARG> (I<xds> or I<fmt> are
+ C<NULL>), C<XDS_ERR_TYPE_MISMATCH> (the format string says the next
+ value is of a particular type, but that's not what we found in the
+ buffer), C<XDS_ERR_UNKNOWN_ENGINE> (an engine name specified in I<fmt>
+ is not registered in I<xds>), C<XDS_ERR_INVALID_MODE> (I<xds> has
+ been initialized in encode mode), C<XDS_ERR_UNDERFLOW> (an engine
+ tried to read more bytes from the buffer than what is data left), or
+ C<XDS_ERR_UNKNOWN> (an engine returned an unspecified error).
+
+ =item int B<xds_decode>(xds_t *I<xds>, const char *I<fmt>, ...);
+
+ This function is basically identical to xds_vdecode(), only that
+ it uses a different prototype syntax.
+
+ =back
+
+ =head1 THE XDR ENGINES
+
+ The B<OSSP xds> distribution ships with a set of engine functions which
+ implement the encoding and decoding for the B<XDR> encoding known from
+ Sun RPC.
+
+ Function Name Expected `args' Input Output
+ ----------------------------------------------------------
+ xdr_encode_uint32() xds_uint32_t 4 bytes 4 bytes
+ xdr_decode_uint32() xds_uint32_t* 4 bytes 4 bytes
+ xdr_encode_int32() xds_int32_t 4 bytes 4 bytes
+ xdr_decode_int32() xds_int32_t* 4 bytes 4 bytes
+ xdr_encode_uint64() xds_uint64_t 4 bytes 4 bytes
+ xdr_decode_uint64() xds_uint64_t* 4 bytes 4 bytes
+ xdr_encode_int64() xds_int64_t 4 bytes 4 bytes
+ xdr_decode_int64() xds_int64_t* 4 bytes 4 bytes
+ xdr_encode_float() xds_float_t 4 bytes 4 bytes
+ xdr_decode_float() xds_float_t* 4 bytes 4 bytes
+ xdr_encode_double() xds_double_t 8 bytes 8 bytes
+ xdr_decode_double() xds_double_t* 8 bytes 8 bytes
+ xdr_encode_octetstream() void*, size_t variable variable
+ xdr_decode_octetstream() void**, size_t* variable variable
+ xdr_encode_string() char* variable variable
+ xdr_decode_string() char** variable variable
+
+ Please note that the functions xdr_decode_octetstream() and
+ xdr_decode_string() return a pointer to a buffer holding the decoded
+ data. This buffer has been allocated with malloc(3) and must be
+ free(3)'ed by the application when it is not required anymore. All other
+ callbacks write the decoded value into the location found on the stack,
+ but these behave differently because the length of the decoded data is
+ not known in advance and the application cannot provide a buffer that's
+ guaranteed to suffice.
+
+ =head1 THE XML ENGINES
+
+ The B<OSSP xds> distribution ships with a set of engine functions which
+ implement the encoding and decoding for an B<XML> based format specified by
+ the included B<XML> DTD.
+
+ Function Name Expected `args' Input Output
+ ----------------------------------------------------------------
+ xml_encode_uint32() xds_uint32_t 4 bytes 8-27 bytes
+ xml_decode_uint32() xds_uint32_t* 18-27 bytes 4 bytes
+ xml_encode_int32() xds_int32_t 4 bytes 16-26 bytes
+ xml_decode_int32() xds_int32_t* 16-26 bytes 4 bytes
+ xml_encode_uint64() xds_uint64_t 8 bytes 18-37 bytes
+ xml_decode_uint64() xds_uint64_t* 18-37 bytes 8 bytes
+ xml_encode_int64() xds_int64_t 8 bytes 16-36 bytes
+ xml_decode_int64() xds_int64_t* 16-36 bytes 8 bytes
+ xml_encode_float() xds_float_t 4 bytes variable
+ xml_decode_float() xds_float_t* variable 4 bytes
+ xml_encode_double() xds_double_t 8 bytes variable
+ xml_decode_double() xds_double_t* variable 8 bytes
+ xml_encode_octetstream() void*, size_t variable variable
+ xml_decode_octetstream() void**, size_t* variable variable
+ xml_encode_string() char* variable variable
+ xml_decode_string() char** variable variable
+
+ Please note that the functions xml_decode_octetstream() and
+ xml_decode_string() return a pointer to a buffer holding the decoded
+ data. This buffer has been allocated with malloc(3) and must be
+ free(3)ed by the application when it is not required anymore. All other
+ callbacks write the decoded value into the location found on the stack,
+ but these behave differently because the length of the decoded data is
+ not known in advance and the application cannot provide a buffer that's
+ guaranteed to suffice.
+
+ =head1 EXTENDING THE LIBRARY
+
+ This section demonstrates how to write a "meta engine" for the B<OSSP
+ xds> framework. The example engine will encode a complex data structure,
+ consisting of three elementary data types. The structure is defined as
+ follows:
+
+ struct mystruct {
+ xds_int32_t small;
+ xds_int64_t big;
+ xds_uint32_t positive;
+ char text[16];
+ };
+
+ Some readers might wonder why the structure is defined using these
+ weird data types rather than the familiar ones like C<int>, C<long>,
+ etc. The reason is that these data types have an undefined size. An
+ C<int> variable will have, say, 32 bits when compiled on the average
+ Unix machine, but when the same program is compiled on a 64-bit machine
+ like Tru64 Unix, it will have a size of 64 bit. This is a problem
+ when those structures have to be exchanged between entirely different
+ systems, because the structures are binary incompatible -- something
+ even B<OSSP xds> cannot remedy, because it is impossible to construct a
+ bidirectional and lossless mapping in this case.
+
+ In order to encode an instance of this structure, we write an encoding
+ engine:
+
+ static int
+ encode_mystruct(
+ xds_t *xds, void *engine_context,
+ void *buffer, size_t buffer_size,
+ size_t *used_buffer_size,
+ va_list *args)
+ {
+ struct mystruct *ms;
+
+ ms = va_arg(*args, struct mystruct*);
+ return xds_encode(xds, "int32 int64 uint32 octetstream",
+ ms->small, ms->big, ms->positive,
+ ms->text, sizeof(ms->text));
+ }
+
+ This engine takes the address of the I<mystruct> structure from the
+ stack and then uses xds_encode() to handle all elements of I<mystruct>
+ separately -- which is fine, because these data types are supported
+ by B<OSSP xds> already (both by the shipped B<XDR> and B<XML> engines). It
+ is worth noting, though, that we refer to the other engines by name,
+ meaning that these engines must be registered in I<xds> by that name
+ before!
+
+ What is very nice, though, is the fact that this encoding engine does
+ not even need to know which particular engines are used to encode the
+ actual values! If the user registere the B<XDR> engines under the
+ appropriate names, I<mystruct> will be encoded in B<XDR>. If the user
+ registers the B<XML> engines under the appropriate names, I<mystruct>
+ will be encoded in B<XML>. Because of that property, we call such an
+ engine a "meta engine".
+
+ Of coures you need not necessarily implement an engine as a "meta
+ engine": Rather than going through xds_encode(), it would be possible
+ to execute the appropriate encoding engines directly. This had the
+ advantage of not depending on those engines being registered at all, but
+ it would make the custom engine depend on the elementary engines -- what
+ is an unnecessary limitation.
+
+ One more word about the engine syntax and semantics: As has been
+ mentioned earlier, any function that adheres to the interface shown
+ above is potentially an engine. These parameters have the following
+ meaning:
+
+ =over 4
+
+ =item I<xds>
+
+ This is the B<OSSP xds> context that was originally provided to the
+ xds_encode() call, which in turn executed the engine. It may be used,
+ for example, for executing xds_encode() again like we did in our example
+ engines.
+
+ =item I<engine_context>
+
+ The engine context can be used by the engine to store any type of
+ internal information. The value the engine will receive must have been
+ provided when the engine was registered by xds_register(). Engines
+ obviously may neglect this parameter if they don't need a context of
+ their own -- all engines included in the distribution do so.
+
+ =item I<buffer>
+
+ This parameter points to the buffer the encoded data should be written
+ to. In decoding mode, I<buffer> points to the encoded data, which should
+ be decoded; the location where the results should be stored at can be
+ found on the stack then.
+
+ =item I<buffer_size>
+
+ The number of bytes available in I<buffer>. In encoding mode, this means
+ "free space", in decoding mode, I<buffer_size> determines how many bytes
+ of encoded data are available in I<buffer> for consumption.
+
+ =item I<used_buffer_size>
+
+ This parameter points to a variable, which the callback must set before
+ returning in order to let the framework know how many bytes it consumed
+ from I<buffer>. A callback encoding, say, an int32 number into a 8 bytes
+ text representation would set the used_buffer_size to 8:
+
+ *used_buffer_size = 8;
+
+ In encoding mode, this variable determines how many bytes the engine has
+ written into I<buffer>; in decoding mode the variable determines how
+ many bytes the engines has read from I<buffer>.
+
+ =item I<args>
+
+ This pointer points to an initialized varadic argument.
+ Use the standard C macro va_arg(3) to fetch the actual data.
+
+ =back
+
+ A callback may return any of the following return codes, as defined in
+ F<xds.h>:
+
+ =over 4
+
+ =item C<XDS_OK>
+
+ No error.
+
+ =item C<XDS_ERR_NO_MEM>
+
+ Failed to allocate required memory.
+
+ =item C<XDS_ERR_OVERFLOW>
+
+ The buffer is too small to hold all encoded data. The callback may set
+ *I<used_buffer_size> to the number of bytes it needs in I<buffer>,
+ thereby giving the framework a hint by how many bytes it should
+ enlarge the buffer before trying the engine again, but just leaving
+ *I<used_buffer_size> alone will work fine too, it may just be a bit less
+ efficient in some cases. Obviously this return code does not make much
+ sense in decoding mode.
+
+ =item C<XDS_ERR_INVALID_ARG>
+
+ Unexpected or incorrect parameters.
+
+ =item C<XDS_ERR_TYPE_MISMATCH>
+
+ This return code will be returned in decoding mode in case the decoding
+ engine realizes that the data it is decoding does not fit what it is
+ expecting. Not all encoding formats will allow to detect this at all.
+ B<XDR>, for example, does not.
+
+ =item C<XDS_ERR_UNDERFLOW>
+
+ In decode mode, this error is be returned when an engine needs, say, 4
+ bytes of data in order to decode a value but I<buffer>/I<buffer_size>
+ provides less.
+
+ =item C<XDS_ERR_UNKNOWN>
+
+ Any other reason to fail than those listed before. Catch all...
+
+ =back
+
+ Let's take a look at the corresponding decoding "meta engine" now:
+
+ static int
+ decode_mystruct(
+ xds_t *xds, void *engine_context,
+ void *buffer, size_t buffer_size,
+ size_t *used_buffer_size,
+ va_list *args)
+ {
+ struct mystruct *ms;
+ size_t i;
+ char *tmp;
+ int rc;
+
+ ms = (struct mystruct *)va_arg(*args, void *);
+ rc = xds_decode(xds, "int32 int64 uint32 octetstream",
+ &(ms->small), &(ms->big), &(ms->positive),
+ &tmp, &i);
+ if (rc == XDS_OK) {
+ if (i == sizeof(ms->text))
+ memmove(ms->text, tmp, i);
+ else
+ rc = XDS_ERR_TYPE_MISMATCH;
+ free(tmp);
+ }
+ return rc;
+ }
+
+ The engine simply calls xds_decode() to handle the separate data types.
+ The only complication is that the octet stream decoding engines return a
+ pointer to malloc(3)ed buffer -- what is not what we need. Thus we have
+ to manually copy the contents of that buffer into the right place in the
+ structure and free the (now unused) buffer again.
+
+ A complete example program encoding and decoding C<mystruct> can be
+ found as F<docs/extended.c> in the B<OSSP xds> source distribution.
+
+ =head1 SEE ALSO
+
+ RFC 1832: `XDR: External Data Representation Standard',
+ R. Srinivasan, August 1995
+
+ XML-RPC Home Page: http://www.xmlrpc.org/
+
+ =head1 HISTORY
+
+ B<OSSP var> was initially written by Peter Simons
+ E<lt>simons@crypt.toE<gt> in August 2001 under contract with the B<OSSP>
+ sponsor B<Cable & Wireless>.
+
+ =cut
+
|
