Yes, it is all transparent to you -unless- you
start trying to calculate offets from a void *,
in which case you must be aware of the padding
issues.
(what to do with the void * param into the
comparison function was what started this whole
line of conversation off, if I recall correctly)
If you cast it to a pointer to the proper struct,
the compiler knows what it's dealing with (padding
and all).
If you use "sizeof(struct xxx)" as the size for
MemMove() et al. then, again, the compiler knows
what it's dealing with padding & all.
But if you write the struct field-by-field into
a data store, then try to read it as a whole into
memory as a struct (or the other way 'round: write
as a whole, attempt to read field-by-field), that's
where the issue of padding might get to you.
--
-Richard M. Hartman
[EMAIL PROTECTED]
186,000 mi./sec ... not just a good idea, it's the LAW!
> -----Original Message-----
> From: Michael S. Davis [mailto:[EMAIL PROTECTED]]
>
>
> On Tue, 23 Mar 1999, Scott Johnson wrote:
>
> > "Michael S. Davis" wrote:
> > > But my questions is, If I use DmWrite and MemMove, is
> that padding
> > > added automatically, with both of these functions.
> >
> > NO -- these functions just copy raw bytes around. The
> parameters you
> > pass specify exactly which bytes, with a 1-byte granularity.
> >
> > If you're familiar with the standard C library, DmWrite and
> MemMove are
> > both Palm equivalents to memmove.
>
> That's easy enough to understand. But what are the implications
> to using these functions and saving and restoring structs that have
> odd length strings (or even length with null term). Are my
> doubles saved and restored properly.
>
> Some have said I must consider the even boundaries for doubles. Or,
> it it that the compiler will compile the struct with or without
> padding (depending on string length) and my DmWrites and MemMove
> just move that data as is. Meaning: that this is all transparent
> to me.
>
