TDF Diagnostic Specification, Issue 3.0

January 1998

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

4. Proposed changes

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.

4.1. Language features currently missing

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.

4.1.1. Data types

Complex numbers.
Fortran alternate RETURNs.

4.1.2. C++ requirements

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 special recognition.
No operations for describing classes and inheritance.

4.1.3. FORTRAN requirements

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 same machine).

4.1.4. Other requirements

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 EXPs are sufficiently powerful, but needs some rules)
No way to name a lexical block.
Formal parameters with default values cannot have the default made visible.
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.

4.2. Areas for further abstraction

4.2.1. Compilation related

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.

4.2.2. C related

At present there is no defined link between the fundamental C types and the 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.

4.2.3. Naming of types

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.

4.3. Postscript - ANDF-DE

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.