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
RETURN
s.
3.1.2. C++ requirements
-
The
reference
type is not yet present. -
The accessibility attributes (
public
,private
andprotected
) are not yet present. -
No
member
function information, and no specification of how to deal with name mangling. Pointer tomember
may need special recognition. -
No operations for describing
class
es and inheritance.
3.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).
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
EXP
s 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.
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 VARIETY
s 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_TYPE
s 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.