- 4.1 - Language features currently missing
- 4.1.1 - Data types
- 4.1.2 - C++ requirements
- 4.1.3 - FORTRAN requirements
- 4.1.4 - Other requirements
- 4.2 - Areas for further abstraction
- 4.2.1 - Compilation related
- 4.2.2 - C related
- 4.2.3 - Naming of types
- 4.3 - Postscript: ANDF-DE
It is thought likely that the new TDF entities described above will
eventually be incorporated into the main TDF specification.
In several places below the absence of "standardised methods"
is noted. These are cases where TDF can express some operation in
several ways, and the installer cannot be expected to spot all of
them and generate new diagnostic info.
The following sections list some of the language features known not
to be supported by the current specification. It is not intended
to be exhaustive.
- Complex numbers.
- Fortran alternate RETURNs.
- The reference type is not yet present.
- The accessibility attributes (public, private and
protected) are not yet present.
- No member function information, and no specification of
how to deal with name mangling. Pointer to member may need
- No operations for describing classes and inheritance.
- Main PROGRAM attribute missing.
- Fortran optional parameters may need special treatment
- Use of COMMON is not explicit in TDF.
- Fortran77 etc. has a string type, which could be implemented in
several ways (other languages need this, but they may differ on the
- No standardised method for describing static link info. TDF can
express such programs, but the link could be stored in several ways.
- No standardised method for describing arrays with either non-constant
bounds, and/or where the bounds are present in the running image.
(The upper_bound and lower_bound
sufficiently powerful, but needs some rules)
- No way to name a lexical block.
- Formal parameters with default values cannot have the default
- Variables which are constant, and have been inlined everywhere
may be a problem.
- No standardised method of describing the discriminant part of
a discriminated union (in TDF probably represented by a struct containing
the discriminant and the union).
- The distinction between ANSI prototyped and non-prototyped functions
(this is a real problem for functions taking float)
- No standardised method for PASCAL sets.
- No standardised method for subrange types.
- PASCAL and Modula have a WITH construct to change semantics
of record field lookup. No standardised method for documenting this.
How a running program has been created from several components is
of interest when debugging. The present system cannot record all details
of how a program has been created. In particular there is no indication
of the source language of any piece of TDF, nor of the full name of
any of the source files.
At present there is no defined link between the fundamental C types
VARIETYs etc. used for them. Present installers
for 32 bit machines cannot distinguish between int and long
when generating diagnostics, other than by means of the standard token
names which form part of the C producer language interface.
At present various
DIAG_TYPEs have names, some don't.
I suspect we should make a separate is_named operation and
remove the other names.
As this section makes clear, the TDF Diagnostic Specification was
only ever really intended to deal with C. As of 1997, a more extensive
diagnostic extension to TDF, ANDF-DE, is under development by DDC-I.
This has been designed with the requirements of C, C++ and Ada in
mind. It is intended that eventually ANDF-DE will be incorporated
into the TDF specification, and the diagnostic format described here
will be denegrated.
Part of the TenDRA Web.
Copyright © 1998.