Re: [boost] offset_cast proposal

From: Pavol Droba (droba_at_[hidden])
Date: 2002-11-25 12:30:04

On Mon, Nov 25, 2002 at 04:52:35PM +0100, Terje Sletteb? wrote:
> >From: "Pavol Droba" <droba_at_[hidden]>
> 
> > On Mon, Nov 25, 2002 at 02:47:54PM +0100, Terje Sletteb? wrote:
> >
> > > How did you do it on the ARM? As I understand, it requires
> > > word-alignment
> > > for words (and half-word alignment for half-words, if that is supported
> > > on
> > > the given ARM version).
> > >
> > Well it is probably a conjuntion of luck and the kind of data we were
> > working
> > with. As I have mentioned before, offset_cast was used mostly for network
> > packet analysis. And fortunately almost all network protocol structures
> > have correct aligmnent. So we were casting only to correct offsets :)
> > 
> Ah, yes, I was thinking of that, too. That's probably designed deliberately
> that way.
> 
> > > > I have mentioned before, that binary analysis could be done also using
> > > > a
> > > > more
> > > > complicated framework. Would it make sense to create one?
> > > >
> > > What does it do?
> >
> > The framework I'm proposing should allow user to specify a structure
> > layout
> > ( like what field starts where and what type if have ). Then there would
> > be a kind of possibly hidden management which would do nescesary copy-in
> > and
> > copy-out operations.
> >
> > I can imagine it should be something like this:
> >
> > void modify_binary_header( void* pData )
> > {
> > binary_struct b;
> > b.add_field<int>( 0, "field1" );
> > b.add_field<char>( 4, "field2" );
> > b.add_field<int>( 5, "field3" );
> >
> > b.map_to_binary( pData, offset );
> >
> > b["field1"]=b["field2"]*2;
> > }
> >
> > Please consider this as very preliminary example, just to show a desired
> > functionality.
> > Construction of  tructure can be probably done in some better way using
> > static templates.
> >
> > Idea is that binary_struct would be responsible to some sort of safe
> > copying ( possibly byte-by-byte )
> > of binary data into/out from the internal field representation. It can
> > provide also some
> > other functionality like byte order corretion or handling of sub-byte
> > fields ( something what
> > is not aligned to byte boundary )
> >
> > Well, this is my idea how to resolve such a problem where simple mapping
> > using offset_cast
> > is not sufficient.
> > 
> Aha, I understand. It's an interesting proposal. I guess it would still
> require some way of detecting, or specifying, alignment requirements (to
> avoid doing it completely pessimistic, by only reading a byte at a time).
> 
>
I think it would have to be some compile time option. I don't know about any way
how to detect it automaticaly.

Anyway, do you think that it's worth to start a discussion about such a library?

It's rather complicated topic to do it right. I have many ideas, but it would take
time to implement them. 

Regards,

Pavol