Re: Big-endian vs little-endian

["Samuel T. Harris" <sam_harris@hso.link.com>]

dennison@telepath.com wrote:
> 
> In article <36BD02DB.737849EE@hso.link.com>,
>   "Samuel T. Harris" <sam_harris@hso.link.com> wrote:
> 
> > also a security concern). Since then, I have always advocated
> > producing width, image, and value functions for all important
> > data types. In fact, I have generics which produce these functions
> > for arrays (trivial) and records (almost trivial) so the overhead
> > for developing these functions is insignificant. An they do come
> > in handy when a little text_io based debugging instrumentation
> > is needed. A simple put_line(image(whatever)); is always available.
> 
> Cool idea! But what method do you use to make generation of records "almost
> trivial"? And how do you handle pointers?
> 

Glad you asked.

Given the requirements that all images look like Ada aggregates,
supporting format options to specify the optional "decorations"
such as qualification and positional vs named notation (which I'll
justify later on in this message), then you have the following
needs for the generics.

A generic for producing width, image, and value functions for
arrays needs to know the type name as a string for qualification,
the width, image, and value functions for the index type
(usually readily available from the appropriate attributes),
the width, image, and value functions for the component type
(possible made available from a previous instantiation of
one of these generics). I believe we all can see the trivial
nature of the width and image functions. The value function
is not so trivial, having to support an optional qualification
and having to deal with named and positional notation. But
its not too difficult once a little effort if put into it.
Of course, an initial version of these generics can be
limited to support positional notation only since this
greatly simplifies the value function.

A generic for producing width, image, and value functions for
records is a little more trouble some. The array generic can
directly use the index to get the component. The record generic
cannot. So, you have to provide extra "helper" functions in the
form of field-level width, image, and value functions. The record
generic needs the type name as a string for qualification,
an enumerated type for all the discriminants and record fields,
the width, image, and value functions for this field-nameing type,
and a width and image function which takes a record object
and field_name and produces the appropriate result (similar
to the component functions of the array generic). It is the
value function which different. It has to be a procedure taking
an in out record object and a field_name with the objective
of filling the appropriate field with the given string.
Each of the helper subprograms uses a simple case statement
to call the appropriate width, image, value for the field
identified. Variant records are no problem since the generic
functions run through all the field names. It is up to the
field-level helper subprogram to either perform an action
or do nothing for fields not in the variant in use.

As far as pointers are concerned, they are outputed as
an allocation by the component (for arrays) or field-level
(for records) subprogram. One may envision a parallel
to the image function called debug which outputs the
pointer itself in some appropriate format so the reader
can track the actual pointers themselves. This is useful
not only for debugging, but also useful when the array
of pointers reuses the same pointer in several slots.
The usage of allocator notation in the image does not
reflect that property. OTOH, output the pointer itself
with its dereference does not satisfy keeping the
image compliant with Ada aggregate notation, so I usually
use a separate subprogram for this or provide options to
image to control the outputed format.

Keeping image compliant with Ada aggregate notation is
important when you consider code which have large aggregates
intializing complex data structures. With a conforming image/value
function pair in place, you can copy the aggregate text
to a file and use the enclosing package elaboration to do
text_io on the file to initialize the data structure with
the image of the file contents. While this will slow down
elaboration, this does allow you change the data structure
without recompiling and relinking the program. I find this
very powerful during development. Once the initial data is
tested and locked down, you can paste it back into the
declaration of the object and comment out the text_io code
in the package elaboration.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Scientific and Technical Systems
"If you can make it, We can fake it!"