Conference azur::mcc

    I'll let Ruth respond with the details on ilv length, but as a general
    principle the encoded ILV buffer is an opaque structure and you should
    not probably not make too many assumptions about its length.  For one
    thing, it could very well be that a given sequence of ILV PUTs yields
    a different length ILV buffer on different hardware platforms and/or
    operating systems.  It could also be that the format changes
    (compatibly) between releases of the software. 

                     <<< Note 1704.0 by TENERE::LAVILLAT >>>
                          -< QUESTION on ILV lengths >-


Two or five questions :

1/ Suppose I read different Attribute lists stored in the MIR using
mcc_mir_read_attr_data. 

Will the mcc_w_curlen field of the data buffer descriptor have always the same
value if the Attribute List contain exactly the same data (encoded in the same
way). 

>If on the same hardware type, currently yes.  I believe that AT THIS VERSION
>the answer is probably yes even if the hardware type is different.  
>The reason is that you are running your "same data" through the "same code"
>using  the "same method" and I certainly hope you get the "same Length".
>However, across hardwares, I am not yet willing to claim that all 
>"constructed/or" data types, especially those
>corresponding to data structures which are differently aligned on
>different hardwares, will always be the same length.  

More generally : will the length of two ILV encoded data buffer be the same if
the data they contain is the same and was encoded in the same way.

Finally (my purpose) : can I be sure that when two ILV constructions are equal
(contain the same data) their length are equal ?

>on the same hardware, encoded by the same method, I believe so.  I am sure 
>the REVERSE statement is NOT true (;-))!

2/ When should be used the mcc_ilv_length routine ? 

>I'm not sure that production code would have a use for it.  Debugging code
>might.  A more specific question such as "is the ilv_length routine useful
>in this (slightly more detailed) situation" will get you a more specific 
>answer.
>
>Do note that the mcc_ilv_length routine will only give the length of
>completed encodings.  Also note that v1.1 and previous ILV code will
>allow you to close off an ilv buffer without having enough "mcc_ilv_put
>cons_ends" before the "mcc_ilv_put_param_end".
>A warning is issued and the buffer is not closed off under these conditions 
>in v1.2

When can I have the mcc_w_curlen field of the descriptor be different from the
mcc_ilv_length returned value ?

>mcc_w_curlen of a newly completed ILV Buffer'S Descriptor is filled in by the
>mcc_ilv_put_param_end routine using the mcc_ilv_length routine.
>I.E. if everthing is O.K., never.  

Is there any existing MCC routine (especially MIR ones) that can modify this
value ?

>If other routines are not modifying
>the ILV encoding, they ought not be modifying the mcc_w_curlen of the ILV 
>encoding Buffer'S Descriptor.
>
>The supplier of the descriptor "owns" it. Most descriptor contents must not
>be modified by MCC routines, or by any other code other than the owner's.  
>Exceptions, such as the dynamic descriptor protocol or the ILV routines' use 
>of the mcc_w_curlen field and
>mcc_b_flags field for very specific communication with the descriptor 
>owner, do exist.  If the MIR routines touch the descriptor, it is
>probably documented in the MIR routine sections of ch 10 and 11 of the
>SRM.

>I hope this contains your answer, somewhere!
>
>Have you seen the mcc_w_curlen of a descriptor of a completed ILV encoding
>altered somewhere?

Ruth K.

>>Have you seen the mcc_w_curlen of a descriptor of a completed ILV encoding
>>altered somewhere?
>

No, never. 

Thanks for your clear and detailed answers.

Pierre.

> Finally (my purpose) : can I be sure that when two ILV constructions are equal
> (contain the same data) their length are equal ?
> 
> >on the same hardware, encoded by the same method, I believe so.  I am sure 
> >the REVERSE statement is NOT true (;-))!

I don't think this assumption is safe.

There are some datatypes which can be "equal" when the values do not contain
the  same  bits.   As a simple example, consider the two simplenames abc and
ABC.   They  are  equal  but  are  not identical.  As a more complex example
consider  the  two  sets  {1,  2}  and {2, 1}.  They are also equal but when
encoded  in  an  ILV  constructor  they  may have the elements opposite ways
round.  

Wildcards confuse things some more: in some contexts A* is regarded as equal
to  ABC.   However, in your case I suspect you aren't interested in that (A*
is different from ABC).

Even without wildcards, the same data may be encoded two ways with different
lengths.   For  example,  consider  {1,  2}  when  encoded  as a bitset: the
BITSTRING  11000  and  the  BITSTRING 110000000000000 are both equally valid
encodings  of  this very same bitset.  In that case the two values are equal
but they are clearly different lengths.

Another example  may  be  a  complex  type  with an optional field where the
optional  field  defaults to some particular value.  A value of this complex
type  without the optional field would be equal to a value with the optional
field  specified  as  the  default  value.   They are likely to be different
lengths.  You could argue that the values are different, even if equal.

Another example  is if one of the values is itself an ASN.1 encoded message.
In that case two messages may be exactly the same ASN.1 information but have
different  lengths  (e.g.   if  one  used  definite  and one used indefinite
encodings).

So the  answer  is:  it  depends  what  you  mean  by  equal.   If  you  are
implementing  a  fairly  general  comparison  routine  (e.g.   for  a filter
expression)  then  you  can't compare lengths.  If you know exactly what the
datatypes  are  which  are  involved  or if you are interested in the values
being  identical  (as  opposed  to  "equal") then a length comparison may be
reasonable.

Graham

Thanks for your replies.

Following your sensible advices I will not use the length of the ILV
buffer for my comparisons.

Re: .4

>So the  answer  is:  it  depends  what  you  mean  by  equal.   If  you  are
>implementing  a  fairly  general  comparison  routine  (e.g.   for  a filter
>expression)  then  you  can't compare lengths.  If you know exactly what the
>datatypes  are  which  are  involved  or if you are interested in the values
>being  identical  (as  opposed  to  "equal") then a length comparison may be
>reasonable.
>

This is it. My problem is comparison of filter expressions, which can contain
any type of data.

Regards.

Pierre.

Don't give up just yet.

What you need is to have a type independant "are these equal" function
for all data types. Sounds like an excellent idea. It ought to be part of the
data type support

Re .6

>What you need is to have a type independant "are these equal" function
>for all data types. Sounds like an excellent idea. It ought to be part of the
>data type support

I agree completely !

There is quite such a thing : if you have two MCC desc. containing any kind of
data, you just need to do an mcc_aes_create using desc. as instance descriptor
and use mcc_aes_equal (or mcc_aes_match) that will cope with any kind of
data-type (or nearby) !

I do not intend to say it is a good way to do it, but I think the code of
this magic compare function should be nearly already written !

Who is volunteer to do the necessary cut from the mcc_aes_equal code ?

Maybe it already exists internally in MCC kernel code ?

I would be very happy to have such a function.

Pierre.

    just watch out, some datatypes in an aes compare will be handled
    case sensitive, either upper or lower before doing this.