3. 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.
3.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.
3.1.1. Data types
-
Complex numbers.
-
Fortran alternate
RETURNs.
3.1.2. C++ requirements
-
The
referencetype is not yet present. -
The accessibility attributes (
public,privateandprotected) are not yet present. -
No
memberfunction information, and no specification of how to deal with name mangling. Pointer tomembermay need special recognition. -
No operations for describing
classes and inheritance.
3.1.3. FORTRAN requirements
-
Main
PROGRAMattribute missing. -
Fortran optional parameters may need special treatment
-
Use of
COMMONis 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).
3.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
WITHconstruct to change semantics of record field lookup. No standardised method for documenting this.
3.2. Areas for further abstraction
3.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.
3.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.
3.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.
3.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.