Comeau C++ 4.0 Pre-Release User Documentation: Environmental

Comeau C++ 4.0
Pre-Release
User-Documentation
Environmental Issues

Environment Variables

The environment variable USR_INCLUDE can be set to a directory to be used instead of /usr/include on the standard include file search list. (Of course, this has no effect if the front end has been configured to have an empty "standard list" of include files.)

The environment variable TMPDIR can be set to indicate a directory to be used for temporary files. If TMPDIR is not set, a default temporary directory (often, /usr/tmp) is used. (Note: at the present time, the front end only uses temporary files when generating an intermediate language file for immediate use by a back end called in the same program, and in the C-generating back end.)
Diagnostic Messages

Diagnostic messages have an associated severity, as follows:
1. Catastrophic errors indicate problems of such severity that the compilation cannot continue. For example: command-line errors, internal errors, and missing include files. If multiple source files are being compiled, any source files after the current one will not be compiled.
2. Errors indicate violations of the syntax or semantic rules of the C or C++ language. Compilation continues, but object code is not generated.
3. Warnings indicate something valid but questionable. Compilation continues and object code is generated (if no errors are detected).
4. Remarks indicate something that is valid and probably intended, but which a careful programmer may want to check. These diagnostics are not issued by default. Compilation continues and object code is generated (if no errors are detected).
Diagnostics are written to stderr with a form like the following:

"test.c",line 5: a break statement may only be used within a loop or switch break; ^Note that the message identifies the file and line involved, and that the source line itself (with position indicated by the ^) follows the message. If there are several diagnostics in one source line, each diagnostic will have the form above, with the result that the text of the source line will be displayed several times, with an appropriate position each time.

Long messages are wrapped to additional lines when necessary.

A configuration flag controls whether or not the string "error:" appears, i.e., the front end can be configured so that the severity string is omitted when the severity is "error".

A command line option may be used to request a shorter form of the diagnostic output in which the original source line is not displayed and the error message text is not wrapped when too long to fit on a single line.

A command line option may be used to request that the error number be included in the diagnostic message. When displayed, the error number also indicates whether the error may have its severity overridden on the command line. If the severity may be overridden, the error number will include the suffix "-D" (for "discretionary"); otherwise no suffix will be present.

"Test_name.c", line 7: error #64-D: declaration does not declare anything struct {}; ^ "Test_name.c", line 9: error #77: this declaration has no storage class or type specifier x; ^
Because an error is determined to be discretionary based on the error severity associated with a specific context, a given error may be discretionary in some cases and not in others.

For some messages, a list of entities is useful; they are listed following the initial error message:
```
"test.c", line 4: error more than one instance of overloaded function "f" matches the argument list:
             function "f(int)"
             function "f(float)"
             argument types are: (double)
     f(1.5);
     ^ 
```
In some cases, some additional context information is provided; specifically, such context information is useful when the front end issues a diagnostic while doing a template instantiation or while generating a constructor, destructor, or assignment operator function. For example:

"test.c", line 7: error: "A::A()" is inaccessible B x; ^ detected during implicit generation of "B::B()" at line 7

Without the context information, it is very hard to figure out what the error refers to.
Termination Messages

By default (this can be changed under a custom porting arrangement), the front end writes sign-off messages to stderr. For example, one of the following forms of message
- n errors detected in the compilation of "ifile".
- 1 catastrophic error detected in the compilation of "ifile".
- n errors and 1 catastrophic error detected in the compilation of "ifile".
is written to indicate the detection of errors in the compilation. No message is written if no errors were detected. The following message
- Error limit reached.
is written when the count of errors reaches the error limit (see the -e option, above); compilation is then terminated. The message
- Compilation terminated.
is written at the end of a compilation that was prematurely terminated because of a catastrophic error. The message
- Compilation aborted.
is written at the end of a compilation that was prematurely terminated because of an internal error. Such an error indicates an internal problem in the compiler and should be reported to Comeau.
Response to Signals

The signals SIGINT (caused by a user interrupt, like ^C) and SIGTERM (caused by a kill command) are trapped by the front end and cause abnormal termination.
Exit Status

On completion, the front end returns with a code indicating the highest-severity diagnostic detected:
- 4 if there was a catastrophic error,
- 2 if there were any errors, or
- 0 if there were any warnings or remarks or if there were no diagnostics of any kind.
If multiple source files are compiled, the exit status indicates the highest-severity diagnostic detected in the entire compilation.

(c)© 1997 Comeau Computing, EDG. All rights reserved.

Comeau Computing
91-34 120th Street
Richmond Hill, NY 11418-3214

Back to documentation Table of Contents
http://www.comeaucomputing.com
support@comeaucomputing.com
/* the end */