To determine whether a certain starttag is the beginning of an inclusion element, a list must be generated for each element containing inclusions. When an element is opened its corresponding list is pushed on the inclusion-stack and when an illegal starttag occurred the inclusion-stack is scanned whether it contains the illegal starttag. If so, the element is an inclusion, if not it is truly an error. Also a list for exclusions is needed, to determine during parsing whether an element may occur, if not an error-message is generated. .sp
.sp 1 The generated lists will be : int incl1[] = { STARTTAG_B, 0 }; int excl1[] = { STARTTAG_C, 0 }; int excl2[] = { STARTTAG_B, 0 };
gen_ex_in() generates such a list for inclusions if str equals ``incl'' or for exclusions when str equals ``excl''. group contains the list-elements and nr contains the number suffix. var_ex_in() generates both lists by calling gen_ex_in() with ``incl'' or ``excl'' and with the corresponding group. The list for exclusions and inclusions is generated on file.
The lexical anylizer must know which strings represent starttags and endtags. Also for each element the corresponding inclusion (5th field) and exclusion (6th field) list must be known, the same goes for the attribute specification list (4th field). The mapname, if there is any, must also be connected to the corresponding element (7th field). The file containing the table is ``tags.i''.
Take the above example, the table will be: .sp Parsertable parserinfo = { { "A", STARTTAG_A, ENDTAG_A, 0, incl1, excl1, 0, 0, 0 }, { "B", STARTTAG_B, ENDTAG_B, 0, 0, excl2, 0, 0, 0 }, { "C", STARTTAG_C, ENDTAG_C, 0, 0, excl2, 0, 0, 0 }, { "D", STARTTAG_D, ENDTAG_D, 0, 0, 0, 0, 0, 0 }, { 0, 0, 0, 0, 0, 0, 0 } };The zero's indicate that the field has no associated list. For instance none of the elements has an attribute specification list, so the fourth field is zero (see generate.desc).