SCHEMATRANS_ENTRY is designed to contain all information needed to initialize a field. In addition, it has multi-line entry capability, which make it possible to support initialization of indirected objects. SCHEMATRANS_ENTRY also accepts a Tcl constructor string and whenever this string is exists, initialization routines will call Tcl_Eval() to evaluate the string, whose result should be a handle to a newly created object, just as in the manner object creation is done. These procedures are done transparently through either of the two routines, shSpptTclObjectInit() and shSpptObjectStateInit(). The former has the capability calling Tcl procedures in addition to what shSpptObjectStateInit() has.
shCnvTblToSchema() performs the actual conversion. It starts by checking the dimensionality of both source and destination. Because C doesn't forbid you overflow a memory boundary, this checking has to be very rigorous. In no circumstances can the source have a larger memory size than that provided by the destination. Once checking passes, shCnvTblToSchema() directly calls p_shSpptCastAndConvert() to copy data. See shSchemaSupport.c for more details.
Note heap type is treated as a special case in shCnvTblToSchema(). Object initialization routines don't operate on fields specified as heap. When shCnvTblToSchema sees a field being specified as heap, it'll call appropriate heap-related routines. Heap fields, whose sizes are known only when the objects are seen, are initialized only within shCnvTblToSchema().
Because we might deal with complicated combinations of static array with heap (e.g, long **ptr[3], where two directions are heap type, whose length derives from other parameters in the same object), the task of shifting pointers to a particular heap block is handled by specialized routines. See shSchemaSupport.c for more details.
Upon converting a set of objects to TBLCOL, we assume that objects are already properly initialized. All we need to do is to properly allocate a memory used by TBLCOL and copy data.
Just as in the case of tblTblSchema, schemaToTbl calls syntax checking routine, which checks for grammar and fills in other necessary information, and then calls shCnvSchemaToTbl.
shCnvSchemaToTbl starts by processing the translation table first. The first pass searches so-called "redundant entries.", namely those entries that designate same "src" name (TBLCOL side, now a destination) but differ only in array index. For example, an entry might use "RA[0]" and another uses "RA[1]". This implies that data may be copied over to different segment of the field -- "RA" in this example -- and the destination field is actually an array. Each different name create a new TBLFLDin TBLCOL. Same names must refer to the same TBLFLD. Processing of translation tables by two routines, shCnvRedundNumGet() and shCnvRedundInfoSet(), results in a run-time association of TBLFLD's names and their memory pointers as well as some other pertinant information like array size, access status etc.
shCnvSchemaToTbl() picks up the information and rigorously perform dimensionality checking just as shCnvTblToSchema does. Heap types, once again, are treated specially by the same set of heap routines used in shCnvTblToSchema. If the dimensionality