Rev 2 | Blame | Compare with Previous | Last modification | View Log | RSS feed
<!-- Crown Copyright (c) 1998 -->
<HTML>
<HEAD>
<TITLE>Proposed changes</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
<H1><A NAME=S49>TDF Diagnostic Specification, Issue 3.0</A></H1>
<H3>January 1998</H3>
<IMG SRC="../images/no_next.gif" ALT="next section"> <A HREF="diag5.html">
<IMG SRC="../images/prev.gif" ALT="previous section"></A>
<A HREF="diag1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
</A>
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
<HR>
<DL>
<DT><A HREF="#S50"><B>4.1</B> - Language features currently missing</A><DD>
<DL>
<DT><A HREF="#S51"><B>4.1.1</B> - Data types</A><DD>
<DT><A HREF="#S52"><B>4.1.2</B> - C++ requirements</A><DD>
<DT><A HREF="#S53"><B>4.1.3</B> - FORTRAN requirements</A><DD>
<DT><A HREF="#S54"><B>4.1.4</B> - Other requirements</A><DD>
</DL>
<DT><A HREF="#S55"><B>4.2</B> - Areas for further abstraction</A><DD>
<DL>
<DT><A HREF="#S56"><B>4.2.1</B> - Compilation related</A><DD>
<DT><A HREF="#S57"><B>4.2.2</B> - C related</A><DD>
<DT><A HREF="#S58"><B>4.2.3</B> - Naming of types</A><DD>
</DL>
<DT><A HREF="#S59"><B>4.3</B> - Postscript: ANDF-DE</A><DD>
</DL>
<HR>
<H1><A NAME=0>4. Proposed changes</A></H1>
It is thought likely that the new TDF entities described above will
eventually be incorporated into the main TDF specification.<P>
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.<P>
<HR>
<H2><A NAME=S50>4.1. Language features currently missing</A></H2>
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.
<H3><A NAME=S51>4.1.1. Data types</A></H3>
<UL>
<LI>Complex numbers.<P>
<LI>Fortran alternate <I>RETURN</I>s.<P>
</UL>
<H3><A NAME=S52>4.1.2. C++ requirements</A></H3>
<UL>
<LI>The <I>reference</I> type is not yet present.<P>
<LI>The accessibility attributes (<I>public</I>, <I>private</I> and
<I>protected</I>) are not yet present.<P>
<LI>No <I>member</I> function information, and no specification of
how to deal with name mangling. Pointer to <I>member</I> may need
special recognition.<P>
<LI>No operations for describing <I>class</I>es and inheritance.<P>
</UL>
<H3><A NAME=S53>4.1.3. FORTRAN requirements</A></H3>
<UL>
<LI>Main <I>PROGRAM</I> attribute missing.<P>
<LI>Fortran optional parameters may need special treatment<P>
<LI>Use of <I>COMMON</I> is not explicit in TDF.<P>
<LI>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).<P>
</UL>
<H3><A NAME=S54>4.1.4. Other requirements</A></H3>
<UL>
<LI>No standardised method for describing static link info. TDF can
express such programs, but the link could be stored in several ways.<P>
<LI>No standardised method for describing arrays with either non-constant
bounds, and/or where the bounds are present in the running image.
(The <I>upper_bound</I> and <I>lower_bound</I> <CODE>EXP</CODE>s are
sufficiently powerful, but needs some rules)<P>
<LI>No way to name a lexical block.<P>
<LI>Formal parameters with default values cannot have the default
made visible.<P>
<LI>Variables which are constant, and have been inlined everywhere
may be a problem.<P>
<LI>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).<P>
<LI>The distinction between ANSI prototyped and non-prototyped functions
(this is a real problem for functions taking <I>float</I>)<P>
<LI>No standardised method for PASCAL sets.<P>
<LI>No standardised method for subrange types.<P>
<LI>PASCAL and Modula have a <I>WITH</I> construct to change semantics
of record field lookup. No standardised method for documenting this.<P>
</UL>
<HR>
<H2><A NAME=S55>4.2. Areas for further abstraction</A></H2>
<H3><A NAME=S56>4.2.1. Compilation related</A></H3>
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.<P>
<H3><A NAME=S57>4.2.2. C related</A></H3>
At present there is no defined link between the fundamental C types
and the <CODE>VARIETY</CODE>s etc. used for them. Present installers
for 32 bit machines cannot distinguish between <I>int</I> and <I>long</I>
when generating diagnostics, other than by means of the standard token
names which form part of the C producer language interface.
<H3><A NAME=S58>4.2.3. Naming of types</A></H3>
At present various <CODE>DIAG_TYPE</CODE>s have names, some don't.
I suspect we should make a separate <I>is_named</I> operation and
remove the other names.<P>
<HR>
<H2><A NAME=S59>4.3. Postscript - ANDF-DE</A></H2>
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.<P>
<HR>
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
Copyright © 1998.</I></P>
</BODY>
</HTML>