Benjamin Zeiss wrote:

Hi Dominic,

Dominic Evans wrote:

...

...

A quick TTCN-3 query which one of you might be able to help with. Telelogic Tau seems to allow the 'char' type here:

const char LF := int2char( 10 ); // line feed, '\n' const char CR := int2char( 13 ); // carriage return, '\r'

But to parse successfully with TRex I found I needed to change char -> byte. Is this due to an extension to the TTCN-3 grammar implemented by Telelogic that automatically typedefs char to byte or am I missing something here?

char is not a built-in type according to the specification. in fact, char seems to be a predefined function which is used in conjunction with universal charstrings to specify char quadruples. i don't think its a good idea to use it as an alias for byte.

Just my two cents:

ETSI ES 201 873-1 contains Annex C (normative): Pre-defined TTCN-3 functions and Annex E (informative): Library of Useful Types where "char" and "int2char" are defined.

"char" and "int2char" are not part of the TTCN-3 BNF (well, actually "char" is used in one place to define UTF quadrapules, but this is another story), but part of these useful types or predifined functions respectively. Hence, it is nothing we shall add to our ANTLR TTCN-3 grammar.

ETSI ES 201 873-1 makes no statement who these types and functions are made visible to a TTCN-3 module, i.e. it is tool specific.

One might think of the C stdlib which is implicitly automatically linked (i.e. implicit add as -lstdlib compiler option) (but still needs to be explictly included by the preprocessor, BTW).

There are several options: You may just add the relevant definitions into your modules which makes trouble (quick & dirty solution) or you may define these types and function as TTCN-3 modules and add a corresponding import statement into each module which uses these types. A more advanced option would be to implictly import this module into each module (or add an option into the preferences page to import it implicitly or not.)

For TRex the easy answer is: "this is tool specific and we decide to not implicitly import useful types and predifined function". The long term answer ist "We should support this."

Now back to the "another story": even if we implicitly import the module with useful type, our parser will complain, because in the TTCN-3 BNF, "char" is a reserved token for quadruple UTF constants, while in the module with useful type, it would be a simple identifier which must not be a reserved token. I do not know, how other tool vendors solve this problem...

Bye, Helmut