| RE:.0
Yes, Richard it is a bug. But it's an MCC bug not a mcc_desframe bug.
Whenever you encode or decode an AES to/from ILV, it expects the
mcc_a_pointer field in the descriptor to point to the actual Abstract
Entity Specification structure itself, not an address of the AES
(single pointer instead of double pointer). This results in many
"interesting" side-effects. Since the only way to do anything with an
AES is by calling the AES routines, and the AES routines *always* pass
the AES's around as double pointers, the only way to use the
descriptors is to pass in the address of the mcc_a_pointer field in the
descriptor. This means that the descriptor class wrong no matter what
you place in it. (If you put CLASS_D, its wrong because it was not
allocated using the O.S. specific string allocation routines, if you
put in CLASS_S, its wrong because it is not "your" static/stack
memory). Also, the length of the buffer being pointed to by the
mcc_a_pointer field is the length of something abstract (the length may
change from one release to another). This bug has caused us so many
headaches that we even gave it its own name. We call it the "AES
double-pointer bug". We have hard-coded "patches" to minimize the
visibility of this bug (if dt = local/full entity then ignore
descriptor class, etc.). You really only notice it when you call
mcc_ilv_get() and mcc_ilv_put() for a datatype of Local Entity and Full
Entity. Remember, whenever you call mcc_ilv_get for a Local/Full
Entity you MUST call mcc_aes_delete( &your_descriptor->mcc_a_pointer ).
Otherwise, you have a memory leak.
My opinion: mcc_desframe_create_descriptor is doing you a favor by
hiding the actual length of the AES.
-Matt.
|