OS/2 Shareware BBS: 10 Tools/10-Tools.zip/JRCPP.ZIP/DIAGNOST.DOC

Text File | 1990-03-27 | 142KB | 2,657 lines

    JRCPP DIAGNOSTIC MESSAGE REFERENCE MANUAL (3/23/90)



    Copyright (C) 1990 James Roskind, All rights reserved. Permission
    is  granted  to copy and distribute this file as part any machine
    readable archive containing the entire, unmodified, JRCPP  PUBLIC
    DISTRIBUTION PACKAGE (henceforth call the "Package").  The set of
    files that form the Package are described in the README file that
    is  a  part  of the Package.  Permission is granted to individual
    users of the Package to copy individual portions of  the  Package
    (i.e.,  component  files) in any form (e.g.: printed, electronic,
    electro-optical, etc.) desired  for  the  purpose  of  supporting
    users   of  the  Package  (i.e.,  providing  online,  or  onshelf
    documentation access; executing the  binary  JRCPP  code,  etc.).
    Permission  is  not  granted  to  distribute copies of individual
    portions of the Package, unless a machine readable version of the
    complete  Package  is also made available with such distribution.
    Abstracting with credit is permitted.   There  is  no  charge  or
    royalty  fee  required  for  copies  made in compliance with this
    notice.  To otherwise copy  elements  of  this  package  requires
    prior permission in writing from James Roskind.

    James Roskind
    516 Latania Palm Drive
    Indialantic FL 32903

    End of copyright notice


What  the  above  copyright  means  is  that  you are free to use and
distribute (or even sell) the entire set of files  in  this  Package,
but  you  can't split them up, and distribute them as separate files.
The notice also says that you  cannot  modify  the  copies  that  you
distribute, and this ESPECIALLY includes NOT REMOVING the any part of
the copyright notice in any file.  JRCPP  currently  implements  a  C
Preprocessor,  but  the  users  of  this Package do NOT surrender any
right of ownership or copyright to any source text that is  processed
by JRCPP, either before or after processing.  Similarly, there are no
royalty or fee requirements for using the post-preprocessed output of
JRCPP.

This  Package is expected to be distributed by shareware and freeware
channels (including BBS sites), but the fees paid for  "distribution"
costs  are  strictly  exchanged  between  the  distributor,  and  the
recipient, and James Roskind makes no express or  implied  warranties
about  the  quality  or integrity of such indirectly acquired copies.
Distributors  and  users  may  obtain   the   Package   (the   Public
distribution form) directly from the author by following the ordering
procedures in the REGISTRATION file.


DISCLAIMER:

JAMES ROSKIND PROVIDES THIS FILE "AS  IS"  WITHOUT  WARRANTY  OF  ANY
KIND,  EITHER  EXPRESS  OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY OR  FITNESS  FOR  A  PARTICULAR
PURPOSE.   THE  ENTIRE  RISK AS TO THE QUALITY AND PERFORMANCE OF THE
PROGRAM AND DOCUMENTATION IS WITH YOU.   Some  states  do  not  allow
disclaimer  of express or implied warranties in certain transactions,
therefore, this statement may not apply to you.


UNIX is a registered trademark of AT&T Bell Laboratories.
____________________________________________________________________



    JRCPP DIAGNOSTIC MESSAGE REFERENCE MANUAL (3/23/90)


INTRODUCTION

The term "diagnostic messages" is meant to be a generalization of the
concept  of  "error  messages".  Diagnostic  messages are any sort of
message that is communicated from the C  Preprocessor  to  the  user.
The  most  common  cause  of  a diagnostic message is an error in the
source code.  Other messages carry information ranging from stylistic
commentary   (e.g.:   "found   '/*'  with  comment"),  or  procedural
commentary (e.g.: "header file  was  found  in  ...  directory"),  to
catastrophic operating systems problems (e.g.: "out of memory").

This  section  begins  with  a  description of the diagnostic message
system, and the meaning of the various diagnostic levels.   A  second
section  provides  a  complete  list  of  the  170+  actual  messages
currently supported, sorted by diagnostic  number.  A  third  section
provides  a  listing of the messages sorted by diagnostic level.  The
last  section  offers  a  detailed  explanation  for  each  supported
messages.


DIAGNOSTIC MESSAGES- OVERVIEW


JRCPP  has  a  fixed list of diagnostic messages, each of which has a
corresponding number.  To  be  complete,  diagnostics  consist  of  a
default  severity  level, an error number, and a textual message. The
possible severity levels include F (fatal), E (error), W (warning), H
(hint),  and  S  (silent).  Error messages numbers range from 1001 to
9999.   Text  of  the  messages  is  typically  less  than  about  60
characters.   When  a  message  is  actually submitted to the user, a
source line number, file name, and relevant text is typically  added,
which brings the entire message line to typically over 80 characters.
The format of the diagnostics is  modeled  after  common  C  compiler
error messaging systems, and standard tools should be able to process
the diagnostics.

One concept that is novel to this JRCPP is  the  distinction  between
the  "default  severity  level"  associated  with  a message, and its
"actual severity level", which is computed  when  the  diagnostic  is
generated.   This  fundamental separation permits users to change the
"actual severity level" of  any  diagnostic  message.  With  no  user
intervention,  the  "actual  severity level" is the "default severity
level", and the user can rely on  the  "factory  settings"  for  each
message.   In  many  other  compilers a user is permitted to change a
threshold or "warning level" in the compiler, in order to change  the
response   to  the  fixed  set  of  diagnostics.   In  contrast,  the
thresholds for response to diagnostics are fixed in  JRCPP,  but  the
user  is  permitted  to  changed  the  severity  level  of any of the
diagnostics.   The  ability  to  change  the  level  associated  with
individual  messages allows the user to customize the compiler to the
individual needs of a project,  and  even  to  specific  sections  of
source code.

In  order  to  support a mechanism that is similar to the traditional
"warning level" setting in other compilers, the  severity  levels  of
whole  groups  of diagnostics with similar severities can be adjusted
at once.  In addition, since the levels can be adjusted in the source
code (via #pragma diagnostic_adjust ...) it is possible to vary these
levels at distinct points in the program (for example:  reducing  the
diagnostic  scrutiny  ONLY during the inclusion of a header file that
is know to be "non-standard" in style and  content).  Adjustment  can
range from preventing a bothersome message from appearing at all, all
the way to the other extreme of forcing the preprocessor to  stop  as
soon as a certain diagnostic is generated.


The   "#pragma  adjust_diagnostic  ..."  directive  can  be  used  to
customize  the  run  time  diagnostic  levels  associated  with  each
message.   It  can  either  change  the  diagnostic levels of all the
diagnostics that share a common level  (e.g.:  change  all  "warning"
diagnostics  to  "error"  diagnostics), or it can specifically change
the diagnostic level of a specific message.  See  the  discussion  of
this under PRAGMA DIRECTIVES, for details of its use.


DIAGNOSTIC MESSAGES- SEVERITY LEVELS

As mentioned earlier, the possible severity levels include F (fatal),
E (error), W (warning), H (hint), and S  (silent).   This  subsection
discusses  the  meaning of each level, along with the philosophy used
to establish default severity levels.

"Fatal" level messages can be expected to terminate the preprocessing
operation immediately.  Moreover, there is generally no facility (via
pragmas) to diminish the diagnostic level of a  message  that  has  a
"fatal"  default severity. Messages are only given a default level of
fatal if: 1) there appears to be no reasonably way  to  recover  from
the  condition;  or  2)  recovery  from the error could inadvertently
damage extraneous files.  Examples of  unrecoverable  errors  include
"out  of  memory",  and  "cannot  open source file".  An example of a
fatal error based upon the second principle is  "unexpected  argument
on  command  line".   If there is an extra argument, then it is quite
possible that the proposed output file is  **NOT**  the  output  file
that  the  user  desired, but is instead an input file!!  Rather than
risking damage to a user's file, a fatal diagnostic is provided,  and
preprocessing ceases.

"Error"  level  messages  indicate  that a significant error has been
detected, but recovery seems possible, and reasonable.   Due  to  the
severity  of  the error, no preprocessed output will be produced, but
preprocessing  will  continue  and  additional  diagnostics  may   be
generated.   Default  settings  of  diagnostics  to "Error" generally
indicate a violation of the ANSI C standard,  and  hence  a  lack  of
"consistent"  portability (i.e.: this is a good chance that some ANSI
C compiler will be totally unable to process the source  file).   The
error recovery that is provided by JRCPP is targeted at compatibility
with prior art that a "Classic C"  preprocessor  might  provide,  and
failing  that, at almost any reasonable error recovery.  For example,
if a totally unrecognized directive is encountered, it was "probably"
a  misspelling  of  a  well  defined  directive.  The  simplest error
recovery strategy is to "ignore" it completely (this also gives  some
sense  of  compatibility  with  future language definitions, or other
"nonstandard" preprocessors). If the user is  satisfied  enough  with
the  recovery, then "#pragma diagnostic ..." directive may be used to
downgrade the level (to a warning or silent) in order to  obtain  the
preprocessed  output.   It  should be clearly understood however that
the source code  that  triggers  diagnostic  with  default  level  of
"error",  might  not  be  preprocessed  identically  by  other ANSI C
preprocessors.

"Warning" level messages indicate that a possibility exists that  the
user  has  made  an error in the source code.  Generally only totally
legal constructs are given a default level of warning.  For  example,
since  comments  do not nest, the presence of a "/*" within a comment
is  syntactically  of  no  consequence.   Based  on  popular   coding
experience,  the  presence  of  a "/*" within a comment is usually an
indication that a prior comment was accidentally not closed (and that
source  code  between  the  two comments is being lost).  It is quite
common for extremely cautious users to upgrade  all  "warning"  level
messages to "error" level in order to guarantee the cleanest of code.

"Silent"  level messages should not be confused with such concepts as
"ignore".  Message are only given a default level of "silent"  if  it
is  believed  that the diagnostic will have almost no practical value
to code diagnosis, and hence  it  should  be  suppressed.   Moreover,
there  is  generally  no  error  recovery needed for default "silent"
level messages.  The most common use of the "silent" level  is  by  a
user,  as  it provides a category to place a "warning" that occurs so
often in the diagnostic listing that it clutters the listing.

The only default "silent" diagnostics are messages that are generally
of no significance to the user.  However, in some debugging scenarios
it is often desirable for a user to be made aware of actions taken by
the  preprocessor,  that  should in general, be ignored. Such actions
are given a default level of "silent", and a user may choose to raise
these  levels  in order to make the activities visible. An example of
this class of message  is  notification  of  where  the  preprocessor
looked to find an include file.  Typically, the preprocessor looks in
several places before finding a file, and the user may  wish  to  see
the exact list of directories searched.

The  existence  of  a  "silent"  level  allows  a user to downgrade a
diagnostic that would otherwise distract code development.  When  the
preprocessor generates a diagnostic, it must generally establish some
meaning for the questionable code, and support its error recovery  by
whatever  actions  are  deemed  appropriate.   This error recovery is
performed independent of the diagnostic level that is  reassigned  to
the  message  by  the  user.   Most simply put, changing a message to
"silent" level only prevents the user from seeing the message, and it
does not change the activities of the preprocessor.

"Hint" level messages indicate a severity somewhere between "warning"
and "silent".  A diagnostic with level "hint" will appear  the  first
time  the  problem  is  encountered,  but will then change its actual
severity level to "silent", and hence never appear again.  This class
of diagnostics are very useful when it is significant to the user (at
least as significant as a warning) that something has been noted, but
it can be expected that TOO MANY other occurrences of this triggering
construct will be diagnosed, and the  diagnostic  file  would  become
cluttered.   If this category were not present, the user would either
be forced to endure endless counts  of  notification  of  a  specific
diagnostic,  or  else  never  receive  notification of a problem.  An
example of the use of default level  "hint"  is  the  presence  of  a
backslash  in  an include file name.  If the user is using this (ANSI
undefined, but JRCPP accepted) construct, then it is likely that  the
user  will  repeat this construct in each #include statement.  With a
default level of hint, this construct will only be diagnosed once.

A user may chose to change the severity level of some diagnostics  to
a  hint  level to remove their dominance from the diagnostic listing,
without accepting them as commonplace  and  silencing  them  totally.
For example, if a user has source code that makes use of $ characters
in identifier names, then it is typically sufficient to  be  notified
the  first  time  this occurs that the construct is in use, but it is
desirable  that  no  further  notification  be  given  (i.e.:   avoid
notification   at  each  occurrence  of  the  offending  identifier).
Similarly, if it is desirable to reduce the number of  warning  level
diagnostics produced by JRCPP, all the default level "warning" can be
changed to "hint", and then each message will occurs at most once  in
the diagnostic listing.


In summary: Fatal  ==> stop immediately
        Error  ==> stop after complete error check of source
        Warning==> continue, but notify user
            Hint   ==> continue, but notify the user the first time only
        Silent ==> continue, and don't notify user


DIAGNOSTIC MESSAGES- CONCISE LIST, SORTED BY DIAGNOSTIC NUMBER


W, 1001, "preserve comment option not supported"
E, 1002, "complex macro predefinition not supported"
E, 1003, "cannot predefine non-identifier"
E, 1004, "unable to predefine macro"
W, 1005, "dependency collection option not yet supported"
E, 1006, "command line option 'p' not supported"
E, 1008, "unrecognized command line option; use -U to undefine macros"
E, 1009, "attempt to undef non-identifier"
W, 1011, "option to restrict names to 8 characters is not supported"
E, 1012, "directory name required"
E, 1013, "unrecognized option"
F, 1014, "unable to open source file"
F, 1015, "output file cannot be the same as input file"
F, 1016, "output file cannot have '.c' postfix"
F, 1017, "unexpected argument on command line"
E, 1018, "identifiers must begin with a letter or '_'"
E, 1018, "identifiers must begin with a letter or '_'"
E, 1019, "valid identifier must contain only alphanumeric or '_'"
E, 1020, "file name in environment variable is too large"
W, 1021, "support for non-ANSI // comments provided"
W, 1022, "__STDC__ definition has been removed"
W, 1023, "ANSI standard macros have been undefined"


E, 2001, "final new line in file is hidden by backslash"
E, 2002, "new line inserted at end of file"
E, 2003, "missing comment terminator '*/' at end of file"


W, 3001, "found "/*" within standard comment"
E, 3002, "illegal vertical whitespace translated to spaces"
E, 3003, "identifier includes '$' character"
W, 3004, "multicharacter character constants not supported"
E, 3005, "character constant missing close quote (')"
E, 3006, "string literal contains invalid escape sequence(s)"
E, 3007, "string literal missing close quote (")"
W, 3008, "illegal character in source stream"
E, 3009, "identifier includes '$' character"
E, 3010, "multicharacter character constants not supported"
E, 3011, "unable to form single token out of character(s)"
E, 3012, "Wide string literal cannot be used as file name"
W, 3013, "escape sequences other than `\\' are not honored in #line directives"
E, 3014, "no text present in file name"
E, 3015, "loss of precision during conversion"
E, 3016, "loss of precision during conversion"
E, 3017, "unable to open preprocessed output file"
E, 3018, "missing terminator on file name"
E, 3019, "file name terminator is not at right end of token"
H, 3020, "#include file name contains "/*" sequence"
H, 3021, "#include file name contains '\' character"
H, 3022, "#include file name contains "'" character"
E, 3023, "invalid file name token in #include directive"
H, 3024, "#include <...> file name contains `"' character"
E, 3025, "cannot open include file"
E, 3026, "existing macro definition being overwritten"
S, 3027, "trying to open include file in ancestor's directory"
S, 3028, "include file found using ancestral path"
S, 3029, "trying to open include file independent of ancestors"
S, 3030, "include file found without ancestral dependence"
F, 3031, "OS reports two input files cannot be opened"
H, 3032, "file temporarily closed"
F, 3033, "unable to temporarily close file"
F, 3034, "OS failure in ftell prevented extension of #include nesting"
F, 3035, "unable to reopen file"
F, 3036, "unable to reposition in file after reopening"
E, 3037, "Unsupported wide character constant translation ignored"
E, 3038, "nil character constant evaluated as single quote  '\'' "
E, 3039, "invalid character constant evaluated in if/elif directive"
E, 3040, "multicharacter character constant truncated during evaluation"
S, 3041, "application include file opened"
S, 3042, "system include file opened"
W, 3043, "found "*/" in "//" style comment"
W, 3044, "found "/*" within standard comment in inactive code"
W, 3045, "found "/*" within "//" style comment"
W, 3046, "found "/*" within "//" style comment in inactive code"
S, 3047, ""//*" may be misunderstood under C++"
W, 3048, ""//*" would be misparsed without "//" style comments"
W, 3049, "illegal vertical whitespace ignored in inactive code"
S, 3050, "identifier includes '$' character in inactive code"
W, 3051, "multicharacter character constant encountered in inactive code"
W, 3052, "character constant missing close quote in inactive code (')"
W, 3053, "string literal in inactive code is missing close quote (")"
W, 3054, "illegal character in inactive code in source stream"
W, 3055, "string literal in inactive code contains invalid escape sequence(s)"
E, 3056, "character constant has no characters"
W, 3057, "character constant in inactive code has no characters"



E, 4001, "unrecognized or unmatched preprocessor directive"
E, 4002, "missing #endif for #if group"
E, 4003, "missing expression for #if directive, FALSE assumed"
E, 4004, "missing identifier name in #ifdef directive, FALSE assumed"
E, 4005, "missing identifier name in #ifndef directive, TRUE assumed"
E, 4006, "syntax error in #if directive, FALSE assumed"
E, 4007, "syntax error in #ifdef directive, FALSE assumed"
E, 4008, "syntax error in #ifndef directive, TRUE assumed"
E, 4009, "missing expression for #elif directive, FALSE assumed"
E, 4010, "syntax error in #elif directive, FALSE assumed"
E, 4011, "unexpected token(s) on line after #else"
W, 4012, "unexpected token(s) on line after #endif"
E, 4013, "missing file name in #include directive"
E, 4016, "unexpected token(s) following file name in #include directive"
E, 4017, "missing line number and file in #line directive"
E, 4018, "first token in #line directive is not a line number"
E, 4019, "second token in #line directive is not a string literal (file name)"
E, 4020, "unexpected 3rd token in #line directive"
E, 4021, "#error encountered; no message provided"
W, 4022, "#pragma missing specification tokens"
E, 4023, "parameter list in macro definition not complete"
E, 4024, "missing identifier name in #define"
E, 4025, "invalid #define directive"
E, 4026, "unexpected token(s) following identifier in #undef"
E, 4027, "non-identifier in #undef directive"
E, 4028, "missing identifier name in #undef"
E, 4029, "syntax error in preprocessor scan"
E, 4030, "syntax error in expanded #if/#elif expression, FALSE assumed"
E, 4031, "syntax error at end of expanded #if/#elif expression, FALSE assumed"
E, 4032, "cannot #define keyword 'defined'"
E, 4033, "cannot #define internal macro name"
E, 4034, "non-benign macro redefinition ignored"
E, 4035, "cannot #define keyword 'defined'"
E, 4036, "cannot #define internal macro name"
E, 4037, "non-benign macro redefinition ignored"
E, 4038, "cannot #undef keyword 'defined'"
E, 4039, "attempted #undef of internal macro ignored"
E, 4040, "function like macro missing ')' after arguments"
E, 4041, "macro has whitespace argument"
E, 4042, "extra arguments to macro ignored"
E, 4043, "macro has solo whitespace argument"
E, 4044, "not enough arguments for macro, whitespace arguments supplied"
E, 4045, "operator '##' ignored at start of replacement list"
E, 4046, "operator '##' ignored at end of replacement list"
E, 4047, "'##' operator followed by '##' operator in macro replacement list"
E, 4048, "'#' operator applied to whitespace"
E, 4049, "operator '##' illegal at start of replacement list"
E, 4050, "operator '#' illegal at end of replacement list"
E, 4051, "operator '#' not followed by a macro parameter"
E, 4052, "operator '##' illegal at end of replacement list"
E, 4053, "line number in #line directive must be between 1 and 32767"
W, 4054, "expected integer or diagnostic level"
W, 4055, "expected 'silent', 'hint', 'warning', or 'error'"
W, 4056, "diagnostic numbers are between 1001 and 9999"
W, 4057, "expected diagnostic number, or severity level"
W, 4058, "expected 'fatal', 'error', 'warning' 'hint' or 'silent'"
W, 4059, "expected ancestral selection and/or 'current_directory'"
E, 4060, "unrecognized pragma undefine_macros selector"
W, 4061, "expected expected 'ANSI', 'platform', 'command_line', or 'user'"
E, 4062, "unrecognized pragma after_output_dump selector"
W, 4063, "expected 'profile' or 'macros'"
W, 4064, "expected 'off', or 'on' (the default is 'on')"
W, 4065, "expected 'off', or 'on' (the default is 'on')"
W, 4066, "expected 'off', or 'on' (the default is 'on')"
W, 4067, "expected 'off', or 'on' (the default is 'on')"
W, 4068, "expected 'off', or 'on' (the default is 'on')"
W, 4069, "unexpected token(s) at end of pragma line ignored"
S, 4070, "benign redefinition of manifest macro ignored"
S, 4071, "benign redefinition of function-like macro ignored"
S, 4072, "macro #undef action undertaken"
W, 4073, "consecutive paste operators in macro definition"
E, 4074, "line number must be a digit sequences only"
W, 4075, "keyword 'defined' evaluated as 0 in if/elif directive"
E, 4076, "scanner limitation: too many characters in pasted string"
S, 4077, "macro #undef requested for undefined identifier"
H, 4078, "use of bulk undefine may limit portability"
H, 4079, "use of bulk undefine may limit portability"
H, 4080, "use of bulk undefine may limit portability"


E, 5001, "#error encountered"
W, 5002, "unrecognized #pragma"
E, 5003, "unexpected token(s) on #ifdef line ignored"
E, 5004, "unexpected token(s) on #ifndef line ignored"
E, 5005, "neither <...> nor "..." style include found"
W, 5006, "cannot change 'fatal' default diagnostic level"
H, 5007, "diagnostic display may be diminished"
E, 5008, "only one ancestral path selection is allowed"
H, 5009, "non-ANSI C behavior requested"
H, 5010, "non-ANSI C behavior requested"
H, 5011, "non-ANSI C behavior requested"
H, 5012, "non-ANSI C behavior requested"
H, 5013, "non-ANSI C behavior requested"


F, 6001, "lexical scanner reading source: ...message..."
F, 6002, "lexical scanner reading pasted text: ...message..."
F, 6003, "preprocessing token parser error"
E, 6004, "#if/elif evaluated false due to: yacc stack overflow"
F, 6005, "out of memory. Object requested was "
F, 6006, "out of memory during character pool reallocation"
F, 6007, "out of memory during concatenation operation"
F, 6008, "out of memory during stringize operation"
F, 6009, "out of memory while unquoting file name"
F, 6010, "out of memory while extracting name in include directive"
F, 6011, "out of memory while extracting directory prefix"
E, 6012, "#if/elif evaluated false due to division by zero"
E, 6013, "#if/elif evaluated false due to modulus of zero"


DIAGNOSTIC MESSAGES GROUPED BY DEFAULT SEVERITY

DIAGNOSTICS WITH DEFAULT SEVERITY OF FATAL ERROR
F, 1014, "unable to open source file"
F, 1015, "output file cannot be the same as input file"
F, 1016, "output file cannot have '.c' postfix"
F, 1017, "unexpected argument on command line"
F, 3031, "OS reports two input files cannot be opened"
F, 3033, "unable to temporarily close file"
F, 3034, "OS failure in ftell prevented extension of #include nesting"
F, 3035, "unable to reopen file"
F, 3036, "unable to reposition in file after reopening"
F, 6001, "lexical scanner reading source: ...message..."
F, 6002, "lexical scanner reading pasted text: ... message..."
F, 6003, "preprocessing token parser error"
F, 6005, "out of memory. Object requested was "
F, 6006, "out of memory during character pool reallocation"
F, 6007, "out of memory during concatenation operation"
F, 6008, "out of memory during stringize operation"
F, 6009, "out of memory while unquoting file name"
F, 6010, "out of memory while extracting name in include directive"
F, 6011, "out of memory while extracting directory prefix"

DIAGNOSTICS WITH DEFAULT SEVERITY OF ERROR
E, 1002, "complex macro predefinition not supported"
E, 1003, "cannot predefine non-identifier"
E, 1004, "unable to predefine macro"
E, 1006, "command line option 'p' not supported"
E, 1008, "unrecognized command line option; use -U to undefine macros"
E, 1009, "attempt to undef non-identifier"
E, 1012, "directory name required"
E, 1013, "unrecognized option"
E, 1018, "identifiers must begin with a letter or '_'"
E, 1018, "identifiers must begin with a letter or '_'"
E, 1019, "valid identifier must contain only alphanumeric or '_'"
E, 1020, "file name in environment variable is too large"
E, 2001, "final new line in file is hidden by backslash"
E, 2002, "new line inserted at end of file"
E, 2003, "missing comment terminator '*/' at end of file"
E, 3002, "illegal vertical whitespace translated to spaces"
E, 3003, "identifier includes '$' character"
E, 3005, "character constant missing close quote (')"
E, 3006, "string literal contains invalid escape sequence(s)"
E, 3007, "string literal missing close quote (")"
E, 3009, "identifier includes '$' character"
E, 3010, "multicharacter character constants not supported"
E, 3011, "unable to form single token out of character(s)"
E, 3012, "Wide string literal cannot be used as file name"
E, 3014, "no text present in file name"
E, 3015, "loss of precision during conversion"
E, 3016, "loss of precision during conversion"
E, 3017, "unable to open preprocessed output file"
E, 3018, "missing terminator on file name"
E, 3019, "file name terminator is not at right end of token"
E, 3023, "invalid file name token in #include directive"
E, 3025, "cannot open include file"
E, 3026, "existing macro definition being overwritten"
E, 3037, "Unsupported wide character constant translation ignored"
E, 3038, "nil character constant evaluated as single quote  '\'' "
E, 3039, "invalid character constant evaluated in if/elif directive"
E, 3040, "multicharacter character constant truncated during evaluation"
E, 3056, "character constant has no characters"
E, 4001, "unrecognized or unmatched preprocessor directive"
E, 4002, "missing #endif for #if group"
E, 4003, "missing expression for #if directive, FALSE assumed"
E, 4004, "missing identifier name in #ifdef directive, FALSE assumed"
E, 4005, "missing identifier name in #ifndef directive, TRUE assumed"
E, 4006, "syntax error in #if directive, FALSE assumed"
E, 4007, "syntax error in #ifdef directive, FALSE assumed"
E, 4008, "syntax error in #ifndef directive, TRUE assumed"
E, 4009, "missing expression for #elif directive, FALSE assumed"
E, 4010, "syntax error in #elif directive, FALSE assumed"
E, 4011, "unexpected token(s) on line after #else"
E, 4013, "missing file name in #include directive"
E, 4016, "unexpected token(s) following file name in #include directive"
E, 4017, "missing line number and file in #line directive"
E, 4018, "first token in #line directive is not a line number"
E, 4019, "second token in #line directive is not a string literal (file name)"
E, 4020, "unexpected 3rd token in #line directive"
E, 4021, "#error encountered; no message provided"
E, 4023, "parameter list in macro definition not complete"
E, 4024, "missing identifier name in #define"
E, 4025, "invalid #define directive"
E, 4026, "unexpected token(s) following identifier in #undef"
E, 4027, "non-identifier in #undef directive"
E, 4028, "missing identifier name in #undef"
E, 4029, "syntax error in preprocessor scan"
E, 4030, "syntax error in expanded #if/#elif expression, FALSE assumed"
E, 4031, "syntax error at end of expanded #if/#elif expression, FALSE assumed"
E, 4032, "cannot #define keyword 'defined'"
E, 4033, "cannot #define internal macro name"
E, 4034, "non-benign macro redefinition ignored"
E, 4035, "cannot #define keyword 'defined'"
E, 4036, "cannot #define internal macro name"
E, 4037, "non-benign macro redefinition ignored"
E, 4038, "cannot #undef keyword 'defined'"
E, 4039, "attempted #undef of internal macro ignored"
E, 4040, "function like macro missing ')' after arguments"
E, 4041, "macro has whitespace argument"
E, 4042, "extra arguments to macro ignored"
E, 4043, "macro has solo whitespace argument"
E, 4044, "not enough arguments for macro, whitespace arguments supplied"
E, 4045, "operator '##' ignored at start of replacement list"
E, 4046, "operator '##' ignored at end of replacement list"
E, 4047, "'##' operator followed by '##' operator in macro replacement list"
E, 4048, "'#' operator applied to whitespace"
E, 4049, "operator '##' illegal at start of replacement list"
E, 4050, "operator '#' illegal at end of replacement list"
E, 4051, "operator '#' not followed by a macro parameter"
E, 4052, "operator '##' illegal at end of replacement list"
E, 4053, "line number in #line directive must be between 1 and 32767"
E, 4060, "unrecognized pragma undefine_macros selector"
E, 4062, "unrecognized pragma after_output_dump selector"
E, 4074, "line number must be a digit sequences only"
E, 4076, "scanner limitation: too many characters in pasted string"
E, 5001, "#error encountered"
E, 5003, "unexpected token(s) on #ifdef line ignored"
E, 5004, "unexpected token(s) on #ifndef line ignored"
E, 5005, "neither <...> nor "..." style include found"
E, 5008, "only one ancestral path selection is allowed"
E, 6004, "#if/elif evaluated false due to: yacc stack overflow"
E, 6012, "#if/elif evaluated false due to division by zero"
E, 6013, "#if/elif evaluated false due to modulus of zero"

DIAGNOSTICS WITH DEFAULT SEVERITY OF WARNING
W, 1001, "preserve comment option not supported"
W, 1005, "dependency collection option not yet supported"
W, 1011, "option to restrict names to 8 characters is not supported"
W, 1021, "support for non-ANSI // comments provided"
W, 1022, "__STDC__ definition has been removed"
W, 1023, "ANSI standard macros have been undefined"
W, 3001, "found "/*" within standard comment"
W, 3004, "multicharacter character constants not supported"
W, 3008, "illegal character in source stream"
W, 3013, "escape sequences other than `\\' are not honored in #line directives"
W, 3043, "found "*/" in "//" style comment"
W, 3044, "found "/*" within standard comment in inactive code"
W, 3045, "found "/*" within "//" style comment"
W, 3046, "found "/*" within "//" style comment in inactive code"
W, 3048, ""//*" would be misparsed without "//" style comments"
W, 3049, "illegal vertical whitespace ignored in inactive code"
W, 3051, "multicharacter character constant encountered in inactive code"
W, 3052, "character constant missing close quote in inactive code (')"
W, 3053, "string literal in inactive code is missing close quote (")"
W, 3054, "illegal character in inactive code in source stream"
W, 3055, "string literal in inactive code contains invalid escape sequence(s)"
W, 3057, "character constant in inactive code has no characters"
W, 4012, "unexpected token(s) on line after #endif"
W, 4022, "#pragma missing specification tokens"
W, 4054, "expected integer or diagnostic level"
W, 4055, "expected 'silent', 'hint', 'warning', or 'error'"
W, 4056, "diagnostic numbers are between 1001 and 9999"
W, 4057, "expected diagnostic number, or severity level"
W, 4058, "expected 'fatal', 'error', 'warning' 'hint' or 'silent'"
W, 4059, "expected ancestral selection and/or 'current_directory'"
W, 4061, "expected expected 'ANSI', 'platform', 'command_line', or 'user'"
W, 4063, "expected 'profile' or 'macros'"
W, 4064, "expected 'off', or 'on' (the default is 'on')"
W, 4065, "expected 'off', or 'on' (the default is 'on')"
W, 4066, "expected 'off', or 'on' (the default is 'on')"
W, 4067, "expected 'off', or 'on' (the default is 'on')"
W, 4068, "expected 'off', or 'on' (the default is 'on')"
W, 4069, "unexpected token(s) at end of pragma line ignored"
W, 4073, "consecutive paste operators in macro definition"
W, 4075, "keyword 'defined' evaluated as 0 in if/elif directive"
W, 5002, "unrecognized #pragma"
W, 5006, "cannot change 'fatal' default diagnostic level"

DIAGNOSTICS WITH DEFAULT SEVERITY OF HINT
H, 3020, "#include file name contains "/*" sequence"
H, 3021, "#include file name contains '\' character"
H, 3022, "#include file name contains "'" character"
H, 3024, "#include <...> file name contains `"' character"
H, 3032, "file temporarily closed"
H, 4078, "use of bulk undefine may limit portability"
H, 4079, "use of bulk undefine may limit portability"
H, 4080, "use of bulk undefine may limit portability"
H, 5007, "diagnostic display may be diminished"
H, 5009, "non-ANSI C behavior requested"
H, 5010, "non-ANSI C behavior requested"
H, 5011, "non-ANSI C behavior requested"
H, 5012, "non-ANSI C behavior requested"
H, 5013, "non-ANSI C behavior requested"

DIAGNOSTICS WITH DEFAULT SEVERITY OF SILENT
S, 3027, "trying to open include file in ancestor's directory"
S, 3028, "include file found using ancestral path"
S, 3029, "trying to open include file independent of ancestors"
S, 3030, "include file found without ancestral dependence"
S, 3041, "application include file opened"
S, 3042, "system include file opened"
S, 3047, ""//*" may be misunderstood under C++"
S, 3050, "identifier includes '$' character in inactive code"
S, 4070, "benign redefinition of manifest macro ignored"
S, 4071, "benign redefinition of function-like macro ignored"
S, 4072, "macro #undef action undertaken"
S, 4077, "macro #undef requested for undefined identifier"



DIAGNOSTIC MESSAGES- EXPLANATIONS AND USER RESPONSES

W, 1001, "preserve comment option not supported"

    The   command   line   option   "-C"  is  understood  by  some  C
    preprocessors  as  a  request   to   preserve   comments   during
    preprocessing.   This  option  is not supported by this facility.
    See "BUGS/FEATURES" for more details.

E, 1002, "complex macro predefinition not supported"

    The command line option "-Didentifier=token"  was  supplied,  but
    the "token" is not a "simple single token".  The "token" supplied
    was either a nil string ("-Didentifier="), or it was  an  invalid
    preprocessing  token,  or  it consisted of multiple tokens (e.g.:
    "-Didentifier=a+b").  The command  line  can  only  be  used  for
    defining  a  token  to be "1" by default (e.g.: "-Didentifier" is
    equivalent to "-Didentifier=1"), or to define  a  manifest  macro
    with a replacement list that consists of a single token.

E, 1003, "cannot predefine non-identifier"

    The  command  line  option "-Didentifier" or "-Didentifier=token"
    was supplied, but "identifier" is not a  valid  identifier  name.
    Valid  names  begin  with  a letter (a-z or A-Z) or an underscore
    ("_"), and continue with a sequence of letters, underscores,  and
    digits  (1-9).  An additional error message (1018 or 1019) should
    provide further description of the nature of the problem.

E, 1004, "unable to predefine macro"

    The command line option  "-Didentifier"  or  "-Didentifier=token"
    was   supplied,   but   the   predefinition  was  NOT  performed.
    Additional  error  messages  should  provide  details   of   what
    prevented the definition.

W, 1005, "dependency collection option not yet supported"

    The  command line option "-M" is understood by some preprocessors
    to mean that a list of dependent files (e.g.: header  files  that
    were  included)  should  be  listed.   This  option  is  used  to
    automatically create dependency  files  for  facilities  such  as
    "make".     This   option   will   be   supported   "soon",   see
    "BUGS/FEATURES" for details.

E, 1006, "command line option 'p' not supported"

    The command line option "-p" is taken by  some  preprocessors  to
    limit  examination  of  identifier  names to 8 characters, and to
    flag extraneous tokens on "#else", and "#endif" lines as  errors.
    The  above  errors  are  always  detected, but this option is not
    supported.

?, 1007, ""

    There is no error 1007.

E, 1008, "unrecognized command line option; use -U to undefine macros"

    A command line option  (a  string  beginning  with  a  "-u")  was
    supplied,  but the characters that followed did not correspond to
    any known options.  Use the "-help" option to get a valid list of
    available options.  Also note that the "-U" option can be used to
    undefine specific macro identifiers.

E, 1009, "attempt to undef non-identifier"

    The  command  line  option  "-Uidentifier"  was   supplied,   but
    "identifier"  is  not a valid identifier name.  Valid names begin
    with a letter (a-z or A-Z) or an underscore ("_"),  and  continue
    with  a  sequence  of  letters, underscores, and digits (1-9). An
    additional error message (1018 or 1019)  should  provide  further
    description of the nature of the problem.

?, 1010, ""

    There is no error 1010.

W, 1011, "option to restrict names to 8 characters is not supported"

    The  command line option "-T" is understood by some preprocessors
    to restrict the significance of identifiers names to 8 characters
    (other   characters  would  be  ignored).   This  option  is  not
    supported.


E, 1012, "directory name required"

    When supplied, this directory name will be appended to the end of
    the   list  of  directory  names  that  were  acquired  from  the
    environment  variable  "INCLUDE".  Unlike  the  traditional   cpp
    counterpart,  the "-Y" option to JRCPP requires a directory name,
    and does not "replace" the existing search list.  This  augmented
    list  of  directories  extends  the  search  path for <...> style
    (a.k.a. system) include directives, as  well  as  "...."  (a.k.a.
    standard)  include  directives.  See also the command line option
    "-I", and the discussion  of  the  #include  directive,  and  the
    searching algorithm used.

E, 1013, "unrecognized option"

    A  command  line  option  (a  string  beginning  with  a "-") was
    supplied, but the characters that followed did not correspond  to
    any known options.  Use the "-help" option to get a valid list of
    available options.

F, 1014, "unable to open source file"

    The first argument on the command line that does not begin with a
    "-"  is  assumed to be the source text file. The preprocessor was
    unable to open the file specified.   Note  that  if  no  file  is
    specified, then standard input is used to obtain the source text.

F, 1015, "output file cannot be the same as input file"

    The  first  two command line arguments that do not begin with "-"
    are assumed to be the source (input) file  and  the  preprocessed
    (output)  file.   The  two  names  supplied are the same, and the
    result would have been that the source file would be destroyed by
    the  preprocessing  execution.   Generally, this is a user error,
    and in order to prevent loss of data,  such  overwriting  is  not
    permitted.

F, 1016, "output file cannot have '.c' postfix"

    The  second command line argument that does not begin with "-" is
    assumed to be the file to which preprocessed data is written.  To
    prevent  a  user from (incorrectly) assuming that several C files
    can be preprocessed at the same time, with the **BAD** result  of
    overwriting  the user's own source file, an output file name with
    the common source postfix ".c" is NOT permitted.  If such a  name
    is  desired,  the  user should either write to an alternate name,
    and then rename the resulting file, or should use redirection  of
    standard  output  (the  default output destination) to create the
    file.

F, 1017, "unexpected argument on command line"

    The presence of a command line argument that does not begin  with
    a  "-" marks the end of the list of options, and the beginning of
    the list of file names (source input, followed optionally  by  an
    output  file  name).  No other arguments should be present on the
    command line beyond this point, but  the  indicated  (extraneous)
    argument was found.

E, 1018, "identifiers must begin with a letter or '_'"

    A command line option provided an "identifier", that did not meet
    the requirements of an  ANSI  C  identifier.   Specifically,  the
    first character was neither a letter nor an underscore ("_").

E, 1019, "valid identifier must contain only alphanumeric or '_'"

    A command line option provided an "identifier", that did not meet
    the requirements of an ANSI  C  identifier.   Specifically,  some
    character  was  neither  a  letter nor an underscore ("_"), nor a
    digit.

E, 1020, "file name in environment variable is too large"

    The environment variable "INCLUDE" is supposed to contain  a  ";"
    delimited  list  of directories to search for include files.  One
    of those directory names exceeded the  static  (sorry,  for  this
    limit,  but  I  doubt  that  it  will bother anyone) limit on the
    length of a directory provided  via  this  environment  variable.
    The  limit  is  currently  511 characters (four times the longest
    legal line length under MSDOS!?!).  Usually this error is  caused
    by  the  presence of a long environment variable called "INCLUDE"
    that  is  actually  **NOT**  a  list  of  directory  names.   See
    "BUGS/FEATURES".


W, 1021, "support for non-ANSI // comments provided"

    The "-B" option was supplied on the command line, and as a result
    the C++ style comments beginning with  "//"  will  be  supported.
    Note  that  this  acceptance is not generally compatible with the
    ANSI C standard. This diagnostic is present in  order  to  comply
    with  the  ANSI  C  Standard that all errors produce at least one
    diagnostic message (and since "//" style comments **MIGHT**  hide
    some code, this message is always provided).

W, 1022, "__STDC__ definition has been removed"

    The  command  line  option "-undef" was supplied, and as a result
    all platform specific macros as well as __STDC__ have  had  their
    definition  removed.   Note  that  the  internal macros __LINE__,
    __FILE__, __DATE__, and __TIME__ are not effected by this option.
    Finer  granularity  of removal of these internally defined macros
    by the "#pragma undefine_macros ...".  This diagnostic is present
    in  order  to  comply  with  the  ANSI C Standard that all errors
    produce at least one diagnostic message (and  since  this  option
    allows  the identifier __STDC__ to be used in a define directive,
    ANSI C violations **MIGHT** be missed later).

W, 1023, "ANSI standard macros have been undefined"

    The command line option  "-undefANSI"  was  provided,  and  as  a
    result  the  internal  macros  __LINE__,  __FILE__, __DATE__, and
    __TIME__ have had their definitions removed. This  diagnostic  is
    present  in  order  to  comply  with the ANSI C Standard that all
    errors produce at least one diagnostic  message  (and  since  the
    macro names that are removed by this mechanism can now become the
    legal subject of #define  and  #undef  directives,  such  ANSI  C
    violations **MIGHT** be missed later).



E, 2001, "final new line in file is hidden by backslash"

    Source  files  must  either be empty, or end in a carriage return
    that is **NOT** logically removed by a preceding backslash.   The
    indicated  file ends with a new line, but the preceding character
    was a backslash. The backslash should be removed.

E, 2002, "new line inserted at end of file"

    All source files must either be empty, or end  in  either  a  new
    line.  The indicated file has a final character that is not a new
    line.  An empty new line should be added to the end of the file.

E, 2003, "missing comment terminator '*/' at end of file"

    The end of file was reached, but a comment was started ("/*") and
    has  not  yet  ended.   Since  all comments are translated into a
    single white space, this error may lead to fairly bizarre errors.
    For  example, if the unterminated comment was initiated on a line
    with a directive, then tokens following the eventual  termination
    of  the  comment  will  appear  logically  on  the  line with the
    directive!?!? To rectify this error, close the comment.  Although
    the  implementation  is CAPABLE OF closing this comment when this
    error occurs, it  was  decided  that  a  **BIZARRE**  user  might
    actually  relish  this performance, and so the comment is **NOT**
    automatically closed.

W, 3001, "found "/*" within standard comment"

    Since standard "/*" based comments do not nest, a "/*"  within  a
    comment  has  no  major significance.  The most common reason for
    this diagnostic is that the user forgot to close a prior comment,
    and  a "/*" indicating the start of a new comment has been found!
    IF this was the reason for the error, then  it  is  quite  likely
    that  some  code  has  also  inadvertently  been  commented  out.
    Without this diagnostic such simple user errors in C are **VERY**
    difficult  to  locate.   As  is suggested by the presence of this
    diagnostic, users should typically not  have  "/*"  within  their
    comments, and this diagnostic can then prove most valuable.  If a
    user wishes temporarily remove  a  block  of  code,  rather  than
    enclosing it in a "/*" based comment, the preprocessor directives
    "#if 0" and "#endif" are suggested  to  enclose  the  block  (and
    these constructs **DO** nest).

E, 3002, "illegal vertical whitespace translated to spaces"

    After  a "#" near the start of a line (preceded only by arbitrary
    whitespace),  the  preprocessor   scans   for   a   preprocessing
    directive.  This  directive  is  terminated  by a newline, and is
    permitted   to   contain   arbitrary   amounts   of   "horizontal
    whitespace".   "Horizontal  whitespace"  includes horizontal tabs
    and spaces (and equivalently  comments).  In  contrast,  vertical
    whitespace,    such    as    a    page-feed,   vertical-tab,   or
    carriage-return, is **NOT** permitted AFTER THE #.  Note that  it
    is  very  difficult to read a listing that has a page feed in the
    middle of a preprocessing directive!  This error  indicates  that
    vertical  whitespace  has  be  detected, and it has been replaced
    with spaces.

E, 3003, "identifier includes '$' character"

    The  ANSI  C  standard  clearly  defines  what   constitutes   an
    identifier  as an alphabetic or underscore character, followed by
    a  sequence  of  alphanumeric  or  underscore  characters.   Some
    machine language implementations make extensive use of the "$" as
    part  of  external   identifiers.    As   a   consequence,   this
    preprocessor  flags  such  a  character in the source stream, but
    scans it in as a complete identifier name. Notice that outside of
    single  and  double  quotes,  the  source  character  "$"  is not
    permitted to be a part of any  standard  token,  and  hence  this
    (clearly  noted)  extension  does not interfere with any standard
    ANSI C constructs.

    For the language lawyers, it should be noted that a $ is actually
    a  valid  preprocessing  token  in  its  own  right.   Hence  the
    "perfect" ANSI C preprocessor would not consider it to be part of
    the  adjacent  identifier(s).   Note  that this exposed character
    does not form a valid token (for parsing), and hence it  must  be
    destroyed or formed into a part of a valid token somewhere during
    preprocessing  activities  (e.g.:  destroyed  because  it  is  an
    argument  to a macro that is not used; made part of a valid token
    by being stringized as part of a macro  expansion).  The  current
    version  of  JRCPP supports the interpretation that a $ character
    defaults to be part of an  identifier,  but  future  versions  of
    JRCPP may require an explicit option to support this feature.


W, 3004, "multicharacter character constants not supported"

    A  character  constant is a single quote, followed by a non-empty
    list of escape sequences  or  characters,  and  terminated  by  a
    single  quote  (example:  '\n').  Although the standard specifies
    what the interpretation of character constants containing exactly
    one  escape  sequence  or  character,  the  ANSI  C  standard  is
    specifically vague in its description of the meaning of  multiple
    characters  (Intel and Motorola architectures generally differ in
    their interpretation of such constants!).  As a result,  portable
    code  SHOULD  NOT make use of character constants containing more
    than one escape sequence or character in a single constant  (this
    has to do, in most cases, with either interpreting such constants
    as "'ab'" as being the same  as  either  "(256*'a'+'b')",  OR  as
    being  the  same  as "(256*'b'+'a')"). Although this preprocessor
    will  process  (as  part  of  source  text)  multiple   character
    constants   as   would   be  expected,  the  interpretation  when
    evaluating "#if" and  "#elif"  directives  does  ***NOT***  honor
    characters  after the first.  Hence for example, "'AB'" is valued
    identically  "'A'"  or  "'Aanything'"  during  preprocessor   #if
    evaluation.   It  is  suggested  that you avoid such not portable
    constructs, and beware of  odd  performance  in  the  context  of
    preprocessor if directives.

E, 3005, "character constant missing close quote (')"

    Character   constants   are   delimited  by  single  quote  ("'")
    characters, and must lie entirely on a single  line.  The  source
    text contains a single quote character which marks the start of a
    character constant, but there is no corresponding close quote  on
    the  same  line.   This  is  typically  a  typo,  but can also be
    instigated by such text as "'\'".  If the user wanted a backslash
    character,  then the source text should have contained "'\\'", to
    provide the single character.  In  contrast,  the  text  "'\'..."
    provides  a  starting  "'",  followed by the ***ESCAPED*** single
    quote character "\'", followed by all the remainder  of  text  on
    that  line.  To correct this error either add the forgotten close
    quote, or properly "escape out" the backslash that  precedes  the
    desired close quote.

E, 3006, "string literal contains invalid escape sequence(s)"

    String  literals  are delimited by double quotes ("), and contain
    source  characters  and  escape  sequences.   The  valid   escape
    sequences  include  "simple escape" sequences such as '\a', '\b',
    '\f', '\n', '\r', '\t', '\v', '\'', '\"', '\?', and '\\', as well
    as   octal   and  hexadecimal  escape  sequences.   Octal  escape
    sequences are of the form '\d', or \'dd', or '\ddd', where 'd' is
    an  octal  digit  between  0 and 7 inclusive.  Hexadecimal escape
    sequences begin with the sequence '\x', and consist of 1 or  more
    additional  alphanumeric  characters.   The presence of any other
    backslash combinations is considered an error,  even  though  the
    sequence is passed correctly through the preprocessor.

E, 3007, "string literal missing close quote (")"

    String  literals are delimited by double quotes ("), and must lie
    entirely on a single line.  This diagnostic  indicates  that  the
    end of the line was reached and the close quote was not provided.
    Note that the escape sequence '\"' can be used to  represent  the
    quote character in an escape sequence, and prevent interpretation
    of the final quote  as  a  delimiter.   For  example,  '"slash=/,
    backslash=\"'  does  not  have  a terminating quote.  The correct
    form of the  above  example  is  '"slash=/,  backslash=\\"'.   To
    correct  this problem, either add the missing quote, or un-escape
    the terminating quote.

W, 3008, "illegal character in source stream"

    A character was found in a source file that cannot be part of any
    preprocessing  token,  in  the  context  of  its occurrence.  For
    example, the backslash character "\" is not part of  any  lexical
    token  when  it  is  outside  of  a  string  literal or character
    constant.  If this lone character is not discarded (such  as  via
    #if  exclusion)  or manipulated into an actual token (such as via
    the stringize operator #), then  this  character  will  cause  an
    error during the phases of compilation FOLLOWING preprocessing.

E, 3009, "identifier includes '$' character"

    This  error  message  is  produced  after  a  macro expansion has
    required pasting of two tokens (re: the  ##  operator),  and  the
    resulting  character  sequence is a non-standard identifier.  See
    diagnostic 3003 for more details.

E, 3010, "multicharacter character constants not supported"

    This diagnostic message is produced after a macro  expansion  has
    required  pasting  of  two  tokens (re: the ## operator), and the
    resulting character sequence is a multicharacter  constant.   See
    diagnostic 3004 for more details.

E, 3011, "unable to form token out of character(s)"

    This  diagnostic  message is produced after a macro expansion has
    required pasting of two tokens (re: the  ##  operator),  and  the
    resulting  character sequence does not form a single preprocessor
    token.  The character sequence will be passed forward  correctly,
    but  these results are not guaranteed to be supported on all ANSI
    C conforming preprocessors.


E, 3012, "Wide string literal cannot be used as file name"

    An attempt was made to use a wide string literal as the name of a
    source file (e.g.: `#line 8 L"name" ').  Since the interpretation
    of wide string literals is implementation  dependent,  and  JRCPP
    does  not  provide  an interpretation for them, this construct is
    poorly defined within JRCPP.  JRCPP will attempt to interpret the
    string  literal  as though it were not a wide string literal, but
    proper interpretation  cannot  be  guaranteed.   The  only  major
    significance  of  this confusion is that the #line directives (if
    any) that are  inserted  in  the  post-preprocessed  output  will
    **NOT**  have notations to indicate that a wide string literal us
    being used.

W, 3013, "escape sequences other than `\\' are not honored  in  #line
directives"

    An escape sequence other than "\\" was found within a  file  name
    specified  in  a  #line directive.  The name provided in a user's
    #line directive is potentially used to form a  name  in  a  #line
    directive  provided  in  the the output (post-preprocessed) file,
    and is also used to identify the location of  a  construct  in  a
    diagnostic  message. Since such sequences as "\n", if interpreted
    as escape sequences, would corrupt the output #line directives as
    well  as  the  format  of  diagnostic  messages.  JRCPP skips the
    backslash that initiates the escape sequence as the file name  is
    scanned.  Note that the "\\" sequence is the only escape sequence
    honored in a file name string supplied in a #line directive.

E, 3014, "no text present in file name"

    A #include directive provided  a  file  name  that  had  no  text
    between the delimiters (e.g.: `#include "" ', or `#include <> ').
    A file name is required in a #include directive.

E, 3015, "loss of precision during conversion"

    The translation  of  the  digit  sequence  provided  in  a  #line
    directive  caused  an  overflow.   This  number  supplied is well
    beyond the range guaranteed by the ANSI C standard (a maximum  of
    32767),  and  moreover,  beyond  the  supported  range  of  JRCPP
    (typically a "signed long" on most architectures).

E, 3016, "loss of precision during conversion"

    The translation  of  the  digit  sequence  provided  in  a  #line
    directive  caused  an  overflow.   This  number  supplied is well
    beyond the range guaranteed by the ANSI C standard (a maximum  of
    32767),  and  moreover,  beyond  the  supported  range  of  JRCPP
    (typically a "signed long" on most architectures).

E, 3017, "unable to open preprocessed output file"

    An attempt was made to open the  output  file  specified  in  the
    command  line, but the operating system call failed.  Check to be
    sure that the file name is valid for your operating system,  that
    access  permission  is  provided  to the specified directory, and
    that access is permitted to the specific file name (i.e.: that  a
    file  by  the  same  name  is  not  already  in  place  AND write
    protected).  Additionally,  there  may  be  restrictions  on  the
    number of open files permitted from the current session, and this
    limit should (when all else fails) be consulted.

E, 3018, "missing terminator on file name"

    An attempt was  made  to  combine  the  tokens  provided  on  the
    #include  line  to form a valid include file name (e.g.: <...> or
    "...").  None of the tokens contained the necessary terminator (>
    or "). The #include directive has been ignored.

E, 3019, "file name terminator is not at right end of token"

    Although  the  left  most  section  of  the  text  of the include
    directive contains a standard file  name  form  (e.g.:  <...>  or
    "..."),  there is some additional text beyond the end of the file
    name sequence.  This text has been ignored.

H, 3020, "#include file name contains "/*" sequence"

    A #include directive contains a file name that has  the  sequence
    `/*'  embedded  within  it.  Such characters cause implementation
    defined behavior.  JRCPP simply accepts such  sequences  as  they
    are  supplied.  Since  this  sequence  is VERY rarely a part of a
    valid file  name,  the  user  is  advised  to  verify  that  such
    placement was intentional.

H, 3021, "#include file name contains '\' character"

    A  #include directive contains a file name that has the character
    `\' within it.   Such  characters  cause  implementation  defined
    behavior.  JRCPP accepts such backslashes, but does **NOT** treat
    them as the start of escape sequences.  For DOS/OS2 applications,
    it is suggested that the equivalent (and generally more portable)
    character `/` be used where a backslash is required as part of  a
    path name.

H, 3022, "#include file name contains "'" character"

    A  #include directive contains a file name that has the character
    "'" within it.   Such  characters  cause  implementation  defined
    behavior.  JRCPP  accepts  such  characters  as  entered (i.e.: a
    single quote).

E, 3023, "invalid file name token in #include directive"

    The "#include" directive expects that the tokens that  follow  it
    are  (or  will  macro  expand  to)  one  of  the file name forms:
    <file_name>, or "file_name".  This error indicates that the  form
    was  not  correct, as should be apparent in the sample text given
    with this  diagnostic.  Note  that  if  the  quoted  form  (i.e.:
    "file_name")  is  used,  then the characters **in** the file name
    cannot be quote characters. Similarly, if the angle bracket  form
    (i.e.:  <file_name>)  is used, the characters in file_name cannot
    include the closing angle bracket ">". This error is  NOT  caused
    by a badly formed file name, or a file that cannot be found.

H, 3024, "#include <...> file name contains `"' character"

    A #include directive of the form <file_name> contains a file name
    that has the double quote character `"' within it.  The  presence
    of  this character causes implementation defined behavior.  JRCPP
    accepts this character as part of the file name.

E, 3025, "cannot open include file"

    This message  indicates  that  the  file  name  selected  in  the
    "#include"  directive either cannot be found, or cannot be opened
    for reading (perhaps due to access restrictions). This error  may
    be  caused by restrictions on the number of open files allowed by
    the specific operating system, either in total, or on a  specific
    (network) device.

E, 3026, "existing macro definition being overwritten"

    The  user  has  elected  to  substitute  the  internal macro name
    __cplusplus for the ANSI C standard macro __STDC__ via (probably)
    the    #pragma    cplusplus_mode   directive.    The   identifier
    "__cplusplus"  was  already  defined  when  this  directive   was
    provided,  and the old definition has been overwritten.  Note the
    the identifier __cplusplus has also  attained  "special  internal
    status", and can no longer be used in as the subject of a #define
    or #undef directives.

S, 3027, "trying to open include file in ancestor's directory"

    A #include directive was specified, and a path prefix  was  taken
    from  one  of the ancestral source files (e.g.: one of the source
    files in the chain of #includes that led to this #include).   The
    diagnostic  shows  the entire path and file name that was used in
    the attempt to open the file.  This  directive  was  provided  to
    allow  users  to  more clearly see the areas searched in order to
    find an included file.   See  the  "#pragma  include_search  ..."
    directive for details on how to control the search algorithm.

S, 3028, "include file found using ancestral path"

    A  file  specified  in  a  #include  directive was located in the
    directory indicated.  Note that the path prefix for this filename
    was  taken  from  one of the ancestral source files (e.g.: one of
    the source files in the chain  of  #includes  that  led  to  this
    #include).   Note  that this message is not produced if the basis
    of the search was the "current directory", or  when  an  absolute
    path  was provided. This directive was provided to allow users to
    more clearly see the areas searched in order to find an  included
    file.  See the "#pragma include_search ..." directive for details
    on how to control the search algorithm.

S, 3029, "trying to open include file independent of ancestors"

    A #include directive was specified, and either an  absolute  path
    was  created,  or  else  the  current  director  was used for the
    search.  Note that  the  location  of  the  file  containing  the
    #include  directive  (as  well  as  the inclusion ancestors) were
    **NOT** involved in creating the path prefix for  this  attempted
    opening  of  the file. This directive was provided to allow users
    to more clearly see the  areas  searched  in  order  to  find  an
    included  file.   See  the "#pragma include_search ..." directive
    for details on how to control the search algorithm.

S, 3030, "include file found without ancestral dependence"

    A file specified in a  #include  directive  was  located  in  the
    directory  indicated.   The  filename used was either an absolute
    path/filename, or else the current directory was used. Note  that
    the  path  prefix for this filename was not derived from the file
    containing the  #include  directive  (or  any  of  the  ancestral
    inclusion  source  files)  This  directive  was provided to allow
    users to more clearly see the areas searched in order to find  an
    included  file.   See  the "#pragma include_search ..." directive
    for details on how to control the search algorithm.

F, 3031, "OS reports two input files cannot be opened"

    An attempt to open a  #include  file  has  been  refused  by  the
    operating  system  with  an  explanation that "too many files are
    open", despite the fact that ONLY one other source  (input)  file
    is  currently  open.  JRCPP temporarily closes source files so as
    not to be constrained by operating restrictions on the number  of
    open  files.  JRCPP's requirements for open files are only stdin,
    stdout, stderr, and at  most  two  source  input  files  (or  one
    post-preprocessing  output file).  This error indicates that such
    resources are not available to  JRCPP,  and  execution  has  been
    terminated.   Check  to be sure that the configuration parameters
    provided are not accidentally set at this incredibly  low  value.
    There  may  also be restrictions due to the use of a network, and
    the number of files that may be open across  the  network  (again
    check  the configuration parameters).  In any case, the resources
    should be made available to JRCPP, and the  preprocessing  should
    be retried.

H, 3032, "file temporarily closed"

    The  level  of  nested #include files has grown large enough that
    the operating system has declared that "too many files are open".
    JRCPP   has   temporarily  closed  a  source  file  in  order  to
    accommodate the operating system, but will reopen the  file  when
    the  contents  must be scanned.  Since there are no static limits
    on the depth of nested includes, this message may be a sign of an
    "infinite  loop"  via  #include  directives.  Alternatively, this
    message may just be a sign that the #include  nesting  is  large,
    and  the  operating  system does not allow many files open at the
    same time. If there is suspicion that the user may  have  induced
    an  "infinite include loop", then the severity of this diagnostic
    should be changed to "Warning", and the activities  can  be  more
    clearly monitored.

F, 3033, "unable to temporarily close file"

    The operating system has refused to allow JRCPP to close a source
    file.   The  indicated  source  file  needed  to  be  closed   to
    accommodate  a restriction by the operating system that "too many
    files were open", which became a problem when the level of nested
    #include  directives  grew too large.  Since the operating system
    refused to allow the  closing  of  the  file,  JRCPP  is  clearly
    confused   about  what  is  going  on  in  the  environment,  and
    preprocessing stops.  This should generally only be caused by  an
    operating system error beyond the control of JRCPP.

F, 3034, "OS failure in ftell prevented extension of #include nesting"

    The operating system restriction of the number of nested #include
    files has caused  JRCPP  to  consider  temporarily  closing  some
    source  file.   Unfortunately,  the  operating  system  call that
    reveals the current location in the source file has failed  (this
    can  occur when the command line has specified that the source be
    taken from standard input, rather than an actual file).

F, 3035, "unable to reopen file"

    The operating system restrictions on the number of files that may
    be  open  at  one time has caused JRCPP to temporarily close some
    source file.  When it was necessary to continue reading from that
    source  file,  an attempt was made to reopen the source file, but
    the operating system request failed.  This rather  unusual  error
    should  only occur if the environment changed (e.g.: the file was
    deleted  or  made  inaccessible)  while  the  source   file   was
    temporarily  closed.   Retry  the preprocessing action, but avoid
    changing the source files WHILE the preprocessor is scanning them.

F, 3036, "unable to reposition in file after reopening"

    The operating system restrictions on the number of files that may
    be  open  at  one time has caused JRCPP to temporarily close some
    source file.  When it was necessary to continue reading from that
    source  file,  the  file  was  reopened, but the operating system
    request to reposition the scan of the file where processing  left
    off,  has failed.  This rather unusual error should only occur if
    the environment changed (e.g.: the file was modified)  while  the
    source  file  was  temporarily  closed.   Retry the preprocessing
    action,  but  avoid  changing  the   source   files   WHILE   the
    preprocessor is scanning them.

E, 3037, "Unsupported wide character constant translation ignored"

    A  #if  or  #elif  directive  required  the  evaluation of a wide
    character  constant.   Since  the  meaning  of   wide   character
    constants  (e.g.: L'...' ) is implementation dependent, and JRCPP
    has no  definition  for  the  interpretation  of  wide  character
    constants,  the  value  is  very likely to be other than what was
    desired by the user.  The character constant will be evaluated as
    though  it were an ordinary character constant (i.e.: the initial
    "L" is ignored).

E, 3038, "nil character constant evaluated as single quote '\'' "

    A #if or #elif directive required the evaluation of  a  character
    constant  that  consisted  of only two consecutive single quotes.
    The value of the constant is taken to be that of a single  quote,
    which is equivalent to: '\''

E, 3039, "invalid character constant evaluated in if/elif directive"

    A  #if  or #elif directive required the evaluation of a character
    constant that was ill formed (it  did  not  include  the  closing
    quote).    The   constant   has  been  interpreted  as  though  a
    terminating quote was supplied.

E,  3040,  "multicharacter character constant truncated during evaluation"

    A #if or #elif directive required the evaluation of  a  character
    constant  that  contained  more  than  a single character.  JRCPP
    interprets  such  constants  as  having  a  value  equal  to  the
    character  constant consisting of only the left most character in
    the constant.  The behavior in this area is not  defined  by  the
    ANSI  C  standard, and the results are notably non-portable.  See
    diagnostic 3004 for more details.

S, 3041, "application include file opened"

    A #include directive of the  form  "file_name"  has  located  the
    requested source file in the directory indicated.  Note that even
    if the search algorithm required the use of the  "system  include
    path",   any   file  requested  via  this  format  provides  this
    diagnostic.  Note also that this diagnostic is silent by default,
    an  will  not  appear  in  diagnostic  listings  unless a #pragma
    diagnostic_adjust directive is used.

S, 3042, "system include file opened"

    A #include directive of the  form  <file_name>  has  located  the
    requested source file in the directory indicated.  Note that this
    diagnostic is silent by default, an will not appear in diagnostic
    listings unless a #pragma diagnostic_adjust directive is used.

W, 3043, "found "*/" in "//" style comment"

    The  character  sequence  */  appears  within  a // style comment
    (i.e.: a comment that begins with //, and continues to the end of
    the  line). Since comments do not nest, the */ has no significant
    whatever. However, an attempt to comment out a  series  of  lines
    using  a /*...*/ style comment would be prematurely terminated by
    this sequence.  This message is only a stylistic warning.

W, 3044, "found "/*" within standard comment in inactive code"

    Inactive  code  is  a  section  of  source  text  that   is   not
    preprocessed   because   of   enclosing   conditional   inclusion
    directives (such as #if ).  A /* was found while passing  over  a
    comment  in  an  inactive  section  of code.  Note that this is a
    common error in active code, as a failure to  close  one  comment
    causes all source code up until the end of the next comment to be
    discarded.  In an inactive code segment, this  stylistic  warning
    might  is  still significant, as a comment can contain what would
    otherwise be considered a preprocessing directive! Hence a #endif
    might  be  accidentally  contained in an erroneously unterminated
    comment.

W, 3045, "found "/*" within "//" style comment"

    The character sequences /* was found within a // style comment. A
    //  style comment begins with //, and continues to the end of the
    current line.  Since comments do not nest in  any  way,  this  /*
    sequence (which would ordinarily indicate the start of a comment)
    is ignored.  If the user has accidentally commented out (via  //)
    the  start  of  a  /*...*/ style comment, then tokens on the next
    line will be exposed (incorrectly) to preprocessing  scan.   This
    warning is only a stylistic warning.

W, 3046, "found "/*" within "//" style comment in inactive code"

    Inactive   code   is  a  section  of  source  text  that  is  not
    preprocessed   because   of   enclosing   conditional   inclusion
    directives  (such as #if ).  The character sequences /* was found
    within a // style comment within a section of inactive  code.   A
    //  style comment begins with //, and continues to the end of the
    current line.  Since comments do not nest in  any  way,  this  /*
    sequence (which would ordinarily indicate the start of a comment)
    is ignored.  If the user has accidentally commented out (via  //)
    the  start  of  a  /*...*/ style comment, then tokens on the next
    line will be exposed (incorrectly) to preprocessing scan, and can
    confuse  the count of #if nesting if they happened to form a #if,
    #else, ... etc. directive.  This  warning  is  only  a  stylistic
    warning.

S, 3047, ""//*" may be misunderstood under C++"

    Although  //  style  comments  are  not  supported,  it may prove
    desirable to support such in future ports of the user's code.   A
    //  style  comment  begins with a //, and continues to the end of
    the current line.  The user has accidentally provided one of  the
    few  character  sequences  that make the use of // style comments
    more difficult.  Specifically, the user has initiated  a  /*...*/
    style  comment  IMMEDIATELY after a divide operator ('/').  If //
    style comments were supported,  this  tokens  sequence  would  be
    misunderstood.   It is suggested that the user place at least one
    blank character after the divide operator. This warning is only a
    stylistic warning.

W, 3048, ""//*" would be misparsed without "//" style comments"

    In  the  indicated  section  of code, // style comments are being
    supported. A // style comment begins with a //, and continues  to
    the  end  of  the  line.  There  is  a chance that the code being
    scanned has an example of the divide operator ('/')  followed  by
    the  start  of  a /*...*/ style comment. This construct, although
    EXTREMELY rare, can be found in ANSI  C  compliant  source  text.
    Since  this  is  an  area  of  ambiguity between the new style //
    comments, and  the  old  style  /*...*/  based  comments,  it  is
    suggested   that   this   text   be   written  less  ambiguously.
    Specifically, it is suggested that a space be placed after the //
    start  of  comment,  and  before  the  *.   This  warning is on a
    stylistic warning.

W, 3049, "illegal vertical whitespace ignored in inactive code"

    Vertical whitespace (such a vertical tab or  page  feed)  in  not
    permitted  (according  to  the ANSI C Standard) to the right of a
    `#' on a line that is interpreted as a  preprocessing  directive.
    Inactive  code  is  a section of text that is not being processed
    because of conditional inclusion directives (such  as  #if).   If
    this  code  were  active,  this  whitespace  character would have
    induced  an  error.   Note  that  vertical  whitespace   may   be
    misconstrued  by  some  preprocessors as the end of the line, and
    allow the characters that  follow  to  be  examined  as  possible
    directive lines.  The user should replace such illegal whitespace
    with horizontal whitespace such as "spaces", or "tabs".

S, 3050, "identifier includes '$' character in inactive code"

    Inactive  code  is  a  section  of  source  text  that   is   not
    preprocessed   because   of   enclosing   conditional   inclusion
    directives (such as #if ).  The `$' character has been  noted  as
    part  of  an  identifier  in  a  section  of  inactive code.  See
    diagnostic 3003 for more details.

W, 3051, "multicharacter character constant encountered in inactive code"

    Inactive   code   is  a  section  of  source  text  that  is  not
    preprocessed   because   of   enclosing   conditional   inclusion
    directives  (such  as  #if ).  Multicharacter character constants
    contain more than one character or escape sequences within a pair
    of  single quotes.  Such constructs are notable non portable, and
    generally  avoided.   Occasionally  an   unterminated   character
    constant is misconstrued for a multicharacter character constant.
    See diagnostic 3004 for more details.


W, 3052, "character constant missing close quote in inactive code (')"

    Inactive  code  is  a  section  of  source  text  that   is   not
    preprocessed   because   of   enclosing   conditional   inclusion
    directives (such as #if ). An incomplete character  constant  was
    identified   within   inactive  code.   Note  that  this  may  be
    indicative of damage to a source file, although it may simply  be
    so conditionally excluded code fragments.

W, 3053, "string literal in inactive code is missing close quote (")"

    Inactive   code   is  a  section  of  source  text  that  is  not
    preprocessed   because   of   enclosing   conditional   inclusion
    directives  (such  as  #if  ).  An  incomplete string literal was
    identified  within  inactive  code.   Note  that  this   may   be
    indicative  of damage to a source file, although it may simply be
    so conditionally excluded code fragments.

W, 3054, "illegal character in inactive code in source stream"

    Inactive  code  is  a  section  of  source  text  that   is   not
    preprocessed   because   of   enclosing   conditional   inclusion
    directives (such as #if ).  Although the fact that  an  arbitrary
    character forms a preprocessing token, and the fact that areas of
    inactive code do not have to form valid tokens of any sort,  this
    error  can  commonly  be  indicative  of  a corrupted source file
    (although it may simply represent the present of  code  fragments
    that were conditionally excluded).

W, 3055, "string literal in inactive code contains invalid escape sequence(s)"

    Inactive   code   is  a  section  of  source  text  that  is  not
    preprocessed   because   of   enclosing   conditional   inclusion
    directives  (such as #if ).  A cursory scan of the text within an
    inactive code sequence revealed that a string  literal  contained
    an  invalid  escape  sequence.   An escape sequence begins with a
    backslash character, and has one of several specific forms.   See
    diagnostic 3006 for more details.

E, 3056, "character constant has no characters"

    A  character  constant  is  either  badly  formed,  or  it has no
    characters. If the user wants to create a constant with  a  value
    equal  to  a single quote, then the correct syntax is '\''.  Note
    that '' actually  has  no  meaning,  and  might  even  have  been
    interpreted  as two consecutive tokens, each of which is a single
    quote.

W, 3057, "character constant in inactive code has no characters"

    Inactive  code  is  a  section  of  source  text  that   is   not
    preprocessed   because   of   enclosing   conditional   inclusion
    directives (such as #if ). A character constant is  either  badly
    formed,  or  it  has no characters. If the user wants to create a
    constant with a value equal to a single quote, then  the  correct
    syntax  is '\''.  Note that '' actually has no meaning, and might
    even have been interpreted as two  consecutive  tokens,  each  of
    which is a single quote.


E, 4001, "unrecognized or unmatched preprocessor directive"

    All  preprocessor  directive  begin  with  a  "#"  as  the  first
    non-white character on the line.  If  the  non-white  token  that
    follows this "#" is not any of the known preprocessing directives
    (e.g.: if, ifdef,  ifndef,  elif,  else,  endif,  pragma,  error,
    define,  undef,  include)  then  the directive is "unrecognized".
    Note that this is significant even within section  of  code  that
    are  "ifdef-ed  out",  in  that  the  preprocessor  is  trying to
    maintain a proper nesting count for if directives. If a  bounding
    preprocessor  directive  (e.g.: elif, else, endif) is encountered
    but it is not syntactically possible to associate it with a prior
    if,   the   the  directive  is  "unmatched".   For  example,  the
    appearance of "#endif" without a prior "#if..."  directive  would
    be an unmatched directive error.

E, 4002, "missing #endif for #if group"

    For   each   preprocessing   if   directive,   there  must  be  a
    corresponding "#endif" directive to terminate the group of  lines
    controlled  by  the  if/ifdef/ifndef.   The  end of file has been
    reached, but the terminating endif has not been found.  Note that
    it is not currently considered worthy of a diagnostic to identify
    when an include file has ended without  terminating  an  if-group
    that  was  begun within that file.  Most of the time, when a user
    erroneously fails to terminate an if directive at any point,  the
    directive  will go unterminated until the complete end of source,
    at which point it will be identified by this diagnostic.

E, 4003, "missing expression for #if directive, FALSE assumed"

    A preprocessing "if" directive is supposed to consist  of  "#if",
    followed by an expression (which must be first macro expanded and
    then evaluated).  This error is produced if EITHER  there  wasn't
    anything  (other than white space after the "if", or if the macro
    expansion of the tokens following the "if" provided no tokens  to
    evaluate.   For  example,  "#define  a" followed by "#if a" would
    result in this error, as the macro "a"  expands  to  nothingness.
    As  a  form  of  error  recovery, the preprocessor acts as if the
    expression evaluated to false (i.e.: 0).

E, 4004, "missing identifier name in #ifdef directive, FALSE assumed"

    The syntax of the #ifdef" directive requires that  an  identifier
    name follow the "ifdef" token.  This error is generated when only
    whitespace follows the "ifdef" directive.  As  a  form  of  error
    recovery, the preprocessor acts as if an identifier was presented
    that was not defined, and hence the directive evaluates to FALSE.

E, 4005, "missing identifier name in #ifndef directive, TRUE assumed"

    The syntax of the #ifndef" directive requires that an  identifier
    name  follow  the  "ifndef"  token.  This error is generated when
    only whitespace follows the "ifndef" directive.   As  a  form  of
    error  recovery,  the  preprocessor  acts as if an identifier was
    presented that was not defined, and hence the directive evaluates
    to TRUE.

E, 4006, "syntax error in #if directive, FALSE assumed"

    A  syntax  error  occurred  while parsing the latter section of a
    "#if" directive.  Since the expression could not  be  read  as  a
    whole,  simplistic error recovery has assumed that the expression
    would have been false (e.g.: 0) anyway.  Note that a common cause
    for  this  problem is the incorrect use of the "defined" operator
    within a "#if" directive.  The only two syntactically valid forms
    are  "defined identifier", and "defined ( identifier )", although
    these forms may be used repeatedly alongside other expressions to
    construct  the complete expression.  Also notice that this syntax
    must be abided by prior to macro expansion, as the  scanning  for
    and  evaluation  of  the  "defined" operator is done **PRIOR** to
    macro evaluation.

E, 4007, "syntax error in #ifdef directive, FALSE assumed"

    A syntax error occurred while parsing the  latter  section  of  a
    "#ifdef"   directive.    The   only   non-white   token  that  is
    syntactically valid after the "ifdef" directive is an identifier.
    If  a  non-identifier is placed at that point then a syntax error
    is produced.  Error  recovery  in  this  case  asserts  that  was
    provided  was not defined (it wasn't even an identifier), and the
    directive evaluates to false.

E, 4008, "syntax error in #ifndef directive, TRUE assumed"

    A syntax error occurred while parsing the  latter  section  of  a
    "#ifndef"   directive.    The   only   non-white  token  that  is
    syntactically  valid  after  the   "ifndef"   directive   is   an
    identifier.   If  a non-identifier is placed at that point then a
    syntax error is produced.  Error recovery in  this  case  asserts
    that was provided was not defined (it wasn't even an identifier),
    and the directive evaluates to true.


E, 4009, "missing expression for #elif directive, FALSE assumed"

    A preprocessing  "elif"  directive  is  supposed  to  consist  of
    "#elif",  followed  by  an  expression (which must be first macro
    expanded and then evaluated).  This error is produced  if  EITHER
    there  wasn't  anything (other than white space after the "elif",
    or the  macro  expansion  of  the  tokens  following  the  "elif"
    provided  no  tokens  to  evaluate.   For example, "#define a" in
    active code, followed much later by "#elif a",  would  result  in
    this  error,  as the macro "a" expands to nothingness.  As a form
    of error recovery, the preprocessor acts  as  if  the  expression
    evaluated to false (i.e.: 0).

E, 4010, "syntax error in #elif directive, FALSE assumed"

    A  syntax  error  occurred  while parsing the latter section of a
    "#elif" directive.  Since the expression could not be read  as  a
    whole,  simplistic error recovery has assumed that the expression
    would have been false (e.g.: 0) anyway.  Note that a common cause
    for  this  problem is the incorrect use of the "defined" operator
    within a "#elif" directive.  The  only  two  syntactically  valid
    forms  are  "defined  identifier",  and "defined ( identifier )",
    although these forms  may  be  used  repeatedly  alongside  other
    expressions  to  construct  the complete expression.  Also notice
    that this syntax must be abided by prior to macro  expansion,  as
    the scanning for and evaluation of the "defined" operator is done
    **PRIOR** to macro evaluation.


E, 4011, "unexpected token(s) on line after #else"

    The "#else" directive is syntactically expected to be alone on  a
    line  (not  counting  whitespace).   This error is generated when
    tokens are found later on  the  line.   Note  that  there  is  no
    significance to these tokens, as they are not processed or passed
    along in any way.

W, 4012, "unexpected token(s) on line after #endif"

    The "#else" directive is syntactically expected to be alone on  a
    line  (not  counting  whitespace).   This error is generated when
    tokens are found later on  the  line.   Note  that  there  is  no
    significance to these tokens, as they are not processed or passed
    along in any way.

E, 4013, "missing file name in #include directive"

    The  preprocessing  "#include"  directive  expects  a  file  name
    (either  enclosed  in quotes, or in angle brackets <...>.  Either
    there is nothing after the  "include"  directive,  or  the  macro
    expansion  of  the  tokens  that  followed  "include" expanded to
    nothingness.  If tokens (other than whitespace)  are  present  on
    the  line  after  "include", check to see that the desired tokens
    and macro definitions are in place.

?, 4014, ""

    There is no diagnostic 4014.

?, 4015, ""

    There is no diagnostic 4015.


E, 4016, "unexpected token(s) following file name in #include directive"

    After macro expanding the token sequence that follows  "#include"
    in  an  "include" directive, the syntax requires that ONLY a file
    name be present.  This error indicates that additional tokens are
    present  on  the  line after the file name, and the error message
    should show the text of the first such token.

E, 4017, "missing line number and file in #line directive"

    This  error  message  is  produced  when  nothing   (other   than
    whitespace)  appears  after  "line"  in a "#line" directive.  The
    syntax requires that the first token be an integer between 1  and
    32767, and that an option second argument specify a file name.

E, 4018, "first token in #line directive is not a line number"

    A  preprocessor  "#line" directive was encountered, but the first
    argument supplied was not  an  integer  constant  (note:  decimal
    points and sign are NOT allowed in an integer constant).

E, 4019, "second token in #line directive is not a string literal (file name)"

    The  second  argument  to  a  "#line"  directive must be a string
    literal (delimited by double quotes `"').  This  error  indicates
    that the second argument is not of the form "file_name".

E, 4020, "unexpected 3rd token in #line directive"

    The  "#line" directive expects no more than 2 arguments, the line
    number to associate with the next line, and the file  name.  This
    error  indicates  that at least one (useless) additional token is
    present after the required arguments.

E, 4021, "#error encountered; no message provided"

    The source text included a "#error" directive.  The line did  not
    have  any addition text to present.  Note that a comment is white
    space,  and  hence  cannot  appear  in  an  "#error"  diagnostic.
    Arbitrary  text  may  be  placed  on  the  line with the "#error"
    directive, and it will have no impact on  the  source  code,  but
    will display with this diagnostic.

W, 4022, "#pragma missing specification tokens"

    The  "#pragma"  directive  is  supposed to include some text with
    implementation defined meaning.   This  error  indicates  that  a
    pragma  was  encountered,  but  there  were no tokens (other than
    whitespace, or equivalently comments) on the  latter  section  of
    the line.

E, 4023, "parameter list in macro definition not complete"

    An  attempt  was  (apparently)  made  to define a "function like"
    macro, but the parameter list was never completed.   A  "function
    like"  macro  is  defined using a "#define" directive, and by not
    leaving a space between the macro name, and  a  parenthesis  that
    follows  it.  This  error  either  indicates  that  the  list  of
    parameters for the macro was never terminated by a ")", or that a
    syntax  error  in  the  parameter  list  stopped the scan for the
    closing parenthesis.  Check to be sure that there  is  a  closing
    ')',  and  that  all  the  parameters are identifiers (you cannot
    leave any out), and that the parameters (if more  than  one)  are
    separated  by  commas.   Typically a syntax error diagnostic will
    accompany this message and reveal where the scan was terminated.

E, 4024, "missing identifier name in #define"

    A "#define"  directive  was  encountered  that  had  nothing  but
    whitespace  after  the "define" keyword.  The "#define" directive
    requires, at a minimum, the name of an identifier to be defined.

E, 4025, "invalid #define directive"

    A  syntax  error  was  encountered  while  scanning  a  "#define"
    directive,  and  hence this directive will be ignored.  The first
    argument to a "#define" directive must be an identifier.  Failure
    to  provide  an  identifier, and to instead provide another token
    (such as a number or an arithmetic operator) is the  most  common
    cause of this diagnostic.

E, 4026, "unexpected token(s) following identifier in #undef"

    Exactly  on  argument  is expected for a "#undef" directive.  The
    argument must be the name of the macro  being  removed  from  the
    macro  database.  This error indicates that some non-white tokens
    (identified in an  associated  syntax  diagnostic)  were  present
    after the identifier name.  Note that these tokens were ignored.

E, 4027, "non-identifier in #undef directive"

    The  token  that  follows  "#undef" in such a directive must be a
    valid identifier name.  This message (and  an  associated  syntax
    diagnostic) indicates that a non-identifier (such as a number, or
    arithmetic operator) was  found  when  the  identifier  name  was
    expected.

E, 4028, "missing identifier name in #undef"

    This  diagnostic  indicates that the "#undef" directive was found
    alone on a line.  The "#undef" directive requires  one  argument,
    specifying  an  identifier,  that is to be removed from the macro
    database.

E, 4029, "syntax error in preprocessor scan"

    The indicated token "confused" the parser, as  the  token  cannot
    reasonably occur where it was found.  An additional error message
    should accompany this message and indicate the context  in  which
    the preprocessor was confused (surprised).

E,  4030,  "syntax  error  in  expanded  #if/#elif  expression, FALSE
assumed"

    This  diagnostic indicates that a sequence of tokens was gathered
    for a "#if"  or  "#elif",  but  after  these  tokens  were  macro
    expanded,  the  resulting  sequence  was  not  a  valid  constant
    expression.  Note that the exact procedure is to: 1)  gather  the
    tokens; 2) replace the "defined" operator with the results of its
    test (0L or 1L); 3) macro expand the  resulting  token  sequence;
    and  4) attempt to evaluate the resulting tokens as having formed
    a constant expression.   This  message  indicates  an  error  was
    encountered in step 4 of this operation.

E, 4031, "syntax error at end of expanded #if/#elif expression, FALSE
assumed"

    This  diagnostic indicates that a sequence of tokens was gathered
    for a "#if"  or  "#elif",  but  after  these  tokens  were  macro
    expanded,  the  resulting  sequence  was  not  a  valid  constant
    expression.  Specifically, there were insufficiently many  tokens
    (e.g.:  there is a missing ')'; or the last token on the line was
    a binary operator, and there is a missing right  operand).   Note
    that  the exact procedure is to: 1) gather the tokens; 2) replace
    the "defined" operator with the results of its test (0L  or  1L);
    3)  macro  expand the resulting token sequence; and 4) attempt to
    evaluate  the  resulting  tokens  as  having  formed  a  constant
    expression.   This  message indicates an error was encountered in
    step 4 of this operation.

E, 4032, "cannot #define keyword 'defined'"

    The preprocessing keyword "defined" has special  significance  in
    the  evaluation  of  "#if"  and "#elif" directives.  As a result,
    ANSI C precludes macro defining this identifier.   This  specific
    diagnostic occurred during an attempt to define "defined" to be a
    manifest macro.

E, 4033, "cannot #define internal macro name"

    There are several internally defined macros that ANSI C precludes
    from  redefinition.  These names are "__STDC__" (or "__cplusplus"
    when  in  c++  mode;  see  sections  on   #pragma),   "__FILE__",
    "__LINE__", "__DATE__", "__TIME__".  This specific diagnostic was
    generated when an attempt was  made  to  redefine  one  of  these
    macros to be an ordinary manifest macro.

E, 4034, "non-benign macro redefinition ignored"

    Once  a  macro  has  been  defined  via a "#define" directive, it
    cannot (without  being  "#undef"-ed  again)  be  the  subject  of
    another  macro  definition,  unless the "redefinition" is "almost
    identical" to the original definition.  The "almost" reflects the
    fact   that  the  nature  of  the  whitespace  contained  in  the
    definition may be altered slightly, but the nonwhite tokens,  and
    the  presence  of separating whitespace, must be unchanged.  This
    ANSI C specification appears to be targeted at allowing  multiple
    header  files, with effectively the same macro definitions, to be
    included without conflicts. Note that it is  NOT  permissible  to
    define  a  macro  to  be  both  a  manifest macro (doesn't have a
    parenthesized list of parameters) AND a function  like  macro  at
    the  same  time.   This specific diagnostic was generated when an
    attempt was made  to  redefine  a  macro  as  a  manifest  macro,
    independent   of   its   former  definition  (which  was  notably
    different).

E, 4035, "cannot #define keyword 'defined'"

    The preprocessing keyword "defined" has special  significance  in
    the  evaluation  of  "#if"  and "#elif" directives.  As a result,
    ANSI C precludes macro defining this identifier.   This  specific
    diagnostic occurred during an attempt to define "defined" to be a
    function like or parameterized macro.

E, 4036, "cannot #define internal macro name"

    There are several internally defined macros that ANSI C precludes
    from  redefinition.  These names are "__STDC__" (or "__cplusplus"
    when  in  c++  mode;  see  sections  on  #pragma)  ,  "__FILE__",
    "__LINE__", "__DATE__", "__TIME__".  This specific diagnostic was
    generated when an attempt was  made  to  redefine  one  of  these
    macros to be a function like, or parameterized macro.

E, 4037, "non-benign macro redefinition ignored"

    Once  a  macro  has  been  defined  via a "#define" directive, it
    cannot (without  being  "#undef"-ed  again)  be  the  subject  of
    another  macro  definition,  unless the "redefinition" is "almost
    identical" to the original definition.  The "almost" reflects the
    fact   that  the  nature  of  the  whitespace  contained  in  the
    definition may be altered slightly, but the nonwhite tokens,  and
    the  presence  of separating whitespace, must be unchanged.  This
    ANSI C specification appears to be targeted at allowing  multiple
    header  files, with effectively the same macro definitions, to be
    included without conflicts. Note that it is  NOT  permissible  to
    define  a  macro  to  be  both  a  manifest macro (doesn't have a
    parenthesized list of parameters) AND a function  like  macro  at
    the  same  time.   This specific diagnostic was generated when an
    attempt was  made  to  redefine  a  macro  function  like  macro,
    independent   of   its   former  definition  (which  was  notably
    different).

E, 4038, "cannot #undef keyword 'defined'"

    The preprocessing keyword "defined" has special  significance  in
    the  evaluation  of  "#if"  and "#elif" directives.  As a result,
    ANSI C precludes macro defining this identifier,  also  precludes
    providing "defined" as the subject of a "#undef" directive (which
    caused this diagnostic).

E, 4039, "attempted #undef of internal macro ignored"

    There are several internally defined macros that ANSI C precludes
    from  redefinition  and  "undefining". These names are "__STDC__"
    (or "__cplusplus" when in c++ mode;  see  sections  on  #pragma),
    "__FILE__",  "__LINE__",  "__DATE__",  "__TIME__".  This specific
    diagnostic was generated when an attempt was made to undefine one
    of these macros.

E, 4040, "function like macro missing ')' after arguments"

    Some  source  text  (or  expanded  source  text)  that  was being
    expanded included an identifier that was defined  as  a  function
    like macro, which had the potential to be expanded.  In addition,
    this identifier was followed by a '(',  which  confirmed  that  a
    expansion    of   the   function   like   macro   was   required.
    Unfortunately, the ')' that marks the end of  the  argument  list
    was not provide (note that parenthesis nest as the search for the
    closing parenthesis is made).  Note that the search for a closing
    ')'  will  NOT  proceed  beyond the next preprocessing directive.
    Hence this diagnostic may be caused by a directive in the  middle
    of   an   argument   list.   See  #pragma  delayed_expansion,  or
    BUGS/FEATURES for details of this scanning limitation.

E, 4041, "macro has whitespace argument"

    One of the arguments to a function like macro invocation (i.e.: a
    point  at  which macro expansion is called for) is missing, or at
    most  there  is  white  space.   For  example:  after  the  macro
    definition  "#define  f(a,b,c)",  the presence of "f(, /*comments
    are  whitespace*/,  )",  would  cause  3   renditions   of   this
    diagnostic.   Note  that  in  the  example  the first argument is
    missing, the second is formed by multiple  whitespaces,  and  the
    third  is formed by a space.  It should also be realized that the
    arguments are identified  BEFORE  they  are  macro  expanded  (if
    needed).   Hence  the  fact  that an argument, AFTER isolation as
    such, expands to nothingness is not generally a  source  of  this
    diagnostic.

E, 4042, "extra arguments to macro ignored"

    A  macro  invocation  of a function like macro has more arguments
    than are prescribed by  its  macro  definition.   The  additional
    arguments are ignored.

E, 4043, "macro has solo whitespace argument"

    The  indicated function like macro was defined to accept a single
    argument, but the invocation of that macro had only whitespace as
    an  argument.   Since arguments are defined by ANSI C to be other
    than whitespace, this is  unacceptable.   As  an  error  recovery
    mechanism,  a  whitespace sequence has been provided as though it
    were the argument.

E,  4044,  "not  enough  arguments  for  macro,  whitespace arguments
supplied"

    The indicated function like macro  was  defined  to  accept  more
    arguments  than  were provided in the indicated invocation.  As a
    form of error recovery, whitespace has been provided  (as  though
    it  were  a  valid  argument)  for  all the undefined (rightmost)
    parameters.

E, 4045, "operator '##' ignored at start of replacement list"

    A macro  definition  had  only  parameters  to  the  left  of  an
    indicated  paste  ("##") operator.  When the macro invocation was
    requested, some additional error recovery caused whitespace to be
    provided  as  arguments  (see  accompanying  diagnostics).   As a
    result of this situation, there was nothing to paste to the  left
    of  the trailing tokens.  The error recovery in this situation is
    too ignore the paste operator.  For example: "#define F(a)  a  ##
    hello",  followed  by  "F()" will produce this diagnostic.  Since
    the arguments that are being placed adjacent to a paste  operator
    are  NOT  expanded prior to placement, the associated diagnostic,
    involving the use of  white  space  as  an  argument,  is  always
    present  when  this  diagnostic  is produced.  Note that not only
    does the  "##"  operator  not  have  any  function,  it  is  also
    prevented  from  activating  paste functionality as it is used is
    the original context (perhaps as an argument).

E, 4046, "operator '##' ignored at end of replacement list"

    A macro definition  had  only  parameters  to  the  right  of  an
    indicated  paste  ("##") operator.  When the macro invocation was
    requested, some additional error recovery caused whitespace to be
    provided  as  arguments  (see  accompanying  diagnostics).   As a
    result of this situation, there was nothing to paste to the right
    of  the  leading tokens.  The error recovery in this situation is
    too ignore the paste operator. For example: "#define  F(a)  hello
    ## a", followed by "F()" will produce this diagnostic.  Since the
    arguments that are being placed adjacent to a paste operator  are
    NOT  expanded  prior  to  placement,  the  associated diagnostic,
    involving the use of  white  space  as  an  argument,  is  always
    present  when  this  diagnostic  is produced.  Note that not only
    does the  "##"  operator  not  have  any  function,  it  is  also
    prevented  from  activating  paste functionality as it is used is
    the original context (perhaps as an argument).

E, 4047, "'##' operator followed by '##' operator in macro replacement list"

    This diagnostic is generated only if the macro is  expanded.   It
    may  be  generated  because  the  a  definition  placed two paste
    operators ("##") consecutively (such as "#define m  hello  ##  ##
    there"),  or as a consequence of a "missing argument" diagnostic.
    An example of the latter case is  "define  F(a)  hello  ##  a  ##
    there",  followed  by "F()".  This diagnostic should be corrected
    by  either  adjusting  the  erroneous  macro  definition   (first
    example),  or  by preventing the associated "whitespace argument"
    error from inducing this problem.  The error recovery  result  of
    this construct is that the token to the left of the first "##" is
    pasted onto the "##" to the right.   This  will  typically  cause
    additional  errors  as the resulting token is scanned (and cannot
    be classified).

E, 4048, "'#' operator applied to whitespace"

    At macro definition time, it was verified that  the  argument  of
    the  stringize  operator  ("#")  was a parameter.  Unfortunately,
    this diagnostic indicates  that  at  macro  invocation  time  the
    corresponding parameter was missing, and whitespace (as indicated
    by accompanying diagnostics) was provided as  an  argument.   The
    error recovery in this situation provided for the construction of
    the string literal with no contents  at  all  (i.e.:  "").   This
    result  is  generally not well defined, as the ANSI C description
    calls for the removal of  all  leading  and  trailing  whitespace
    before  creating  the string, while at the same time it indicates
    that internal whitespace should be reduced to a single space.

E, 4049, "operator '##' illegal at start of replacement list"

    This diagnostic indicates that a macro  definition  has  a  paste
    operator  ("##")  at the start of the replacement list. Since the
    paste operator requires a  left  operand  (and  pasting  is  done
    BEFORE plugging the complete macro expansion into its surrounding
    context), the paste operator is guaranteed to  not  have  a  left
    argument,  and  hence  will  not  perform  any action.  The error
    recovery in this context is to simply leave the paste operator at
    the  start  of  the replacement list.  Note that it is internally
    prevented from inducing a paste operation in other contexts (such
    as when provided as an argument to another macro).

E, 4050, "operator '#' illegal at end of replacement list"

    The  replacement  list  for  a macro ends in a stringize operator
    ("#"). Since the operator requires a right operand, there  is  no
    possibility  that  a  macro  invocation  would provide such.  The
    error recovery in this situation  involves  effectively  deleting
    the trailing "#" from the macro definition.

E, 4051, "operator '#' not followed by a macro parameter"

    The  right  operand  of  the  stringize operator ("#") in a macro
    definition is not a parameter.  The meaningless "#" is discarded.
    Normally the token just to the right of "#" in a replacement list
    is a parameter  for  the  macro,  and  the  intent  is  that  the
    corresponding  argument  be  stringized  (enclosed  gracefully in
    quotes) at macro invocation time.

E, 4052, "operator '##' illegal at end of replacement list"

    This diagnostic indicates that a macro  definition  has  a  paste
    operator  ("##")  at  the  end of the replacement list. Since the
    paste operator requires a right  operand  (and  pasting  is  done
    BEFORE plugging the complete macro expansion into its surrounding
    context), the paste operator is guaranteed to not  have  a  right
    argument,  and  hence  will  not  perform  any action.  The error
    recovery in this context is to simply leave the paste operator at
    the  end  of  the  replacement  list.  Note that it is internally
    prevented from inducing a paste operation in other contexts (such
    as when provided as an argument to another macro).

E, 4053, "line number in #line directive must be between 1 and 32767"

    For  compatibility  with  a  variety  of  implementations, ANSI C
    requires that the first argument (the line number) in  a  "#line"
    directive  be  in  the  range  of  1-32767.   This implementation
    actually supports any line numbers less than 2<<31 (2 to the 31st
    power).  Note  that  negative  line numbers cannot be entered, as
    they are actually evaluated as an expression, including a leading
    unary  minus  operator,  and hence would cause syntax errors in a
    "#line" directive.


W, 4054, "expected integer or diagnostic level"

    The #pragma diagnostic_adjust  was  selected,  but  the  required
    arguments  were  not  supplied.   JRCPP assumes that the macro is
    only accidentally named identically to JRCPP's pragma, and so the
    pragma is passed unchanged to the post-preprocessed output file.

W, 4055, "expected 'silent', 'hint', 'warning', or 'error'"

    A #pragma diagnostic_adjust directive was provided, but the first
    argument was an identifier other than the a valid severity level.
    The two arguments to diagnostic_adjust are a severity level (or a
    specific  diagnostic  number),  followed  by  a  users  specified
    severity   level.    This  pragma  is  processed  as  though  the
    similarity to a valid JRCPP  pragma  was  coincidental,  and  the
    directive  is  passed  unchanged to the post-preprocessing output
    file.

W, 4056, "diagnostic numbers are between 1001 and 9999"

    A #pragma diagnostic_adjust directive was provided, but the first
    argument  was  an  integer outside the valid range for diagnostic
    numbers.  The two arguments to diagnostic_adjust are  a  severity
    level  (or  a  specific  diagnostic  number), followed by a users
    specified severity level.  This pragma is processed as though the
    similarity  to  a  valid  JRCPP  pragma was coincidental, and the
    directive is passed unchanged to  the  post-preprocessing  output
    file.

W, 4057, "expected diagnostic number, or severity level"

    A #pragma diagnostic_adjust directive was provided, but the first
    argument was neither an  integer  nor  and  identifier.  The  two
    arguments  to  diagnostic_adjust  are  a  severity  level  (or  a
    specific  diagnostic  number),  followed  by  a  users  specified
    severity   level.    This  pragma  is  processed  as  though  the
    similarity to a valid JRCPP  pragma  was  coincidental,  and  the
    directive  is  passed  unchanged to the post-preprocessing output
    file.


W, 4058, "expected 'fatal', 'error', 'warning' 'hint' or 'silent'"

    A #pragma  diagnostic_adjust  directive  was  provided,  but  the
    second  argument  was  not  a  valid  severity  level.   The  two
    arguments  to  diagnostic_adjust  are  a  severity  level  (or  a
    specific  diagnostic  number),  followed  by  a  users  specified
    severity level. This pragma is processed as though the similarity
    to  a  valid  JRCPP pragma was coincidental, and the directive is
    passed unchanged to the post-preprocessing output file.

W, 4059, "expected ancestral selection and/or 'current_directory'"

    A  #pragma  include_search  directive  was  provided,   but   the
    arguments  were  not  valid  for this pragma.  There should be at
    most two arguments, one of which specifies the extent (if any) of
    the    use   of   ancestral   files   and   their   path   prefix
    (only_eldest_ancestor,     OR      only_youngest_ancestor      OR
    all_ancestors),  and one argument that specifies the use (if any)
    of the current directory as a  path  prefix  (current_directory).
    This  pragma  is  processed  as  though the similarity to a valid
    JRCPP pragma  was  coincidental,  and  the  directive  is  passed
    unchanged to the post-preprocessing output file.

E, 4060, "unrecognized pragma undefine_macros selector"

    The  "#pragma undefine_macros ..." directive was encountered, but
    one of the arguments was not a valid macro group selector.  Since
    a  prior  selector was valid, the scan of this directive will NOT
    be  abandoned.  The  valid   groups   include   "ANSI",   "STDC",
    "platform",  "command_line",  and "user".  Note that the "#pragma
    after_output_dump macros" can be use to  obtain  a  list  of  the
    contents of each of these macro groups. This specific argument is
    being ignored, and the scan of  the  otherwise  valid  pragma  is
    continuing.  Note that this error simply marks the exclusion of a
    single argument, and if later arguments are  present  and  valid,
    then they will be accepted and processed.

W, 4061, "expected expected 'ANSI',  'platform',  'command_line',  or
'user'"

    The  "#pragma undefine_macros ..." directive was encountered, but
    none of the arguments was not a valid macro group selector.   The
    valid  groups include "ANSI", "STDC", "platform", "command_line",
    and "user". Note  that  the  "#pragma  after_output_dump  macros"
    lists  the  contents  of  each  of  these  macro groups. Since no
    meaning could be ascribed to this #pragma,  the  pragma  will  be
    passed unchanged to the output file.

E, 4062, "unrecognized pragma after_output_dump selector"

    A  "#pragma after_output_dump ..." directive was encountered, but
    the indicated argument was neither 'profile' nor  'macros'.  This
    specific   argument  is  being  ignored,  and  the  scan  of  the
    potentially valid pragma is  continuing.  Note  that  this  error
    simply  marks  the  exclusion  of a single argument, and if other
    arguments are present and correct, then they will be acted upon.

W, 4063, "expected 'profile' or 'macros'"

    A #"pragma after_output_dump" directive was encountered, but none
    of  the  arguments  were valid selectors ('profile' or 'macros').
    Since no meaning could be ascribed to this  #pragma,  the  pragma
    will be passed unchanged to the output file.

W, 4064, "expected 'off', or 'on' (the default is 'on')"

    A  "#pragma delayed_expansion" directive was encountered, but the
    argument was other than 'on', 'off',  or  nothing.  Setting  this
    option  to 'on' allows directives that cannot change the state of
    the macro database to occur during an argument list for  a  macro
    invocation.  Since  no meaning could be ascribed to this #pragma,
    the pragma will be passed unchanged to the output file.

W, 4065, "expected 'off', or 'on' (the default is 'on')"

    A "#pragma cplusplus_comment" directive was encountered, but  the
    argument  was  other  than  'on', 'off', or nothing. Setting this
    option to 'on' causes the lexical scan of source text to  support
    the  //  style  comments.   Since no meaning could be ascribed to
    this #pragma, the pragma will be passed unchanged to  the  output
    file.

W, 4066, "expected 'off', or 'on' (the default is 'on')"

    A  "#pragma describe_macro_expansions" directive was encountered,
    but the argument was other than 'on', 'off', or nothing.  Setting
    this  option  to  'on' directs JRCPP to provide an explanation of
    the macro expansion process as  the  next  group  of  tokens  are
    expanded.  Note  that groups of tokens that are expanded together
    are typically bounded by  directives.   Hence  a  pair  of  these
    pragmas  can be used to turn this option on for only a few lines,
    and then turn it back off.  Since no meaning could be ascribed to
    this  #pragma,  the pragma will be passed unchanged to the output
    file.

W, 4067, "expected 'off', or 'on' (the default is 'on')"

    A "#pragma space_between_tokens" directive was  encountered,  but
    the argument was other than 'on', 'off', or nothing. Setting this
    option to 'off'  directs  JRCPP  to  avoid  adding  extra  spaces
    between  consecutive tokens as the output file is generated. Note
    that the actual output file is generated after the entire  source
    text  has  been preprocessed, and hence it is generally of little
    value to alternately turn this feature off and then on. Since  no
    meaning  could  be  ascribed  to this #pragma, the pragma will be
    passed unchanged to the output file.

W, 4068, "expected 'off', or 'on' (the default is 'on')"

    A "#pragma display_progress" directive was encountered,  but  the
    argument  was  other  than  'on', 'off', or nothing. Setting this
    option to 'on' causes a series of status messages  to  appear  on
    stderr,  so  that  progress  of  JRCPP can be monitored. Since no
    meaning could be ascribed to this #pragma,  the  pragma  will  be
    passed unchanged to the output file.

W, 4069, "unexpected token(s) at end of pragma line ignored"

    JRCPP  was  able  to  interpret  and act based upon the indicated
    pragma. However, there were additional tokens on the end  of  the
    line that are being ignored.

S, 4070, "benign redefinition of manifest macro ignored"

    A define directive redefined an existing manifest macro.  The new
    definition is similar enough to the previous definition that  the
    action  is  considered  benign  (i.e., has no impact).  Note that
    this diagnostic is silent, but users may chose to raise its level
    in order to quickly identify header files that are being included
    repeatedly (and wastefully providing the same macro definitions).
    Although  the  redefinition  is  benign, it may also be a symptom
    that several distinct files have the same definitions (which  may
    identify a problem before it becomes significant).

S, 4071, "benign redefinition of function-like macro ignored"

    A  define  directive  redefined  an existing function like macro.
    The new definition is similar enough to the  previous  definition
    that the action is considered benign (i.e., has no impact).  Note
    that this diagnostic is silent, but users may chose to raise  its
    level  in  order  to quickly identify header files that are being
    included repeatedly (and  wastefully  providing  the  same  macro
    definitions).   Although  the redefinition is benign, it may also
    be  a  symptom  that  several  distinct  files  have   the   same
    definitions  (which  may  identify  a  problem  before it becomes
    significant).

S, 4072, "macro #undef action undertaken"

    A #undef directive was encountered, and the indicated  macro  was
    defined.   The  macro  is  now  being  undefined.  Note that this
    diagnostic is silent, but may prove useful if there is a question
    of where a given macro was undefined.

W, 4073, "consecutive paste operators in macro definition"

    A  macro  definition  was provided that had two consecutive paste
    operators  ("##").   If  this  macro  is  ever  expanded   (i.e.,
    invoked), then a more severe diagnostic will be produced.

E, 4074, "line number must be a digit sequences only"

    A #line directive was encountered, but the line number was not of
    the expected  format.   Specifically,  an  integer  constant  was
    provided  with  a suffix of either 'u', 'l', 'U', or 'L', or some
    combination (as is valid for an integer constant).   The  postfix
    is ignored.

W, 4075, "keyword 'defined' evaluated as 0 in if/elif directive"

    Macro expansion of the token sequence in a #if or #elif directive
    created the identifier 'defined'.  Since  the  keyword  'defined'
    only  has  special meaning before the macro expansion process, it
    is treated like any other  identifier,  and  replaced  with  '0'.
    Since  this  is  an  area  were  the  results  are implementation
    defined, this construct might not be portable.  It  is  suggested
    that  you  avoid  the use of the identifier 'defined' in a #if or
    #elif directive, and use ONLY the  operator  'defined'  prior  to
    macro expansion.

E, 4076, "scanner limitation: too many characters in pasted string"

    The result of a paste operator ("##") in a macro replacement list
    has created a token with a long spelling.  This token is so large
    that  it  exceeds  the  buffer  size of the lexical analyser that
    "reclassifies"  such  tokens.    This   reclassification   should
    actually  have  no significance unless the token is used in a #if
    or #elif directive.  Fundamentally this diagnostic indicates that
    a static limit in JRCPP has been exceeded.

S, 4077, "macro #undef requested for undefined identifier"

    A  #undef directive was encountered, but the named identifier was
    not currently defined.  Hence this directive had no effect.  Note
    that   this  diagnostic  is  silent,  but  may  prove  useful  in
    diagnosing  incorrectly  typed  identifier  names  in  an   undef
    directive.

H, 4078, "use of bulk undefine may limit portability"

    The  directive  "#pragma  undefine_macros platform" has requested
    that several macros be undefined (specifically,  all  the  macros
    that  are  provided  by  JRCPP  as  platform  specific, including
    _JRCPP). Since this pragma is not a an ANSI standard feature, the
    underlying  source  file  may  not be fully portable (i.e., other
    implementation would still have the  macro  definitions  intact).
    Since this directive is commonly used in conjunction with JRCPP's
    capability  of  precalculating  a  combined  header  file,  which
    requires  JRCPP  functionality,  this  diagnostic  is often quite
    acceptable.

H, 4079, "use of bulk undefine may limit portability"

    The  directive   "#pragma   undefine_macros   command_line"   has
    requested that several macros be undefined (specifically, all the
    macros that were defined on the command line).  Since this pragma
    is not a an ANSI standard feature, the underlying source file may
    not be fully portable (i.e.,  other  implementation  would  still
    have the macro definitions, if any, intact). Since this directive
    is commonly  used  in  conjunction  with  JRCPP's  capability  of
    precalculating  a  combined  header  file,  which  requires JRCPP
    functionality, this diagnostic is often quite acceptable.

H, 4080, "use of bulk undefine may limit portability"

    The directive "#pragma undefine_macros user" has  requested  that
    several  macros  be  undefined (specifically, all the macros that
    have been defined from within  any  source  files).   Since  this
    pragma  is  not a an ANSI standard feature, the underlying source
    file may not be fully portable (i.e., other implementation  would
    still  have  the  macro  definitions, if any, intact). Since this
    directive is commonly used in conjunction with JRCPP's capability
    of  precalculating  a  combined header file, which requires JRCPP
    functionality, this diagnostic is often quite acceptable.

E, 5001, "#error encountered"

    A "#error" directive was found in active code (i.e.: it  was  not
    ifdef-ed  out).   The text following the directive is supplied as
    part of the diagnostic.

W, 5002, "unrecognized #pragma"

    A "#pragma" directive was encountered, but the text that followed
    was meaningless to this preprocessor.  The pragma will be present
    in the preprocessed output, but whitespace within the pragma will
    not be preserved.

E, 5003, "unexpected token(s) on #ifdef line ignored"

    A  "#ifdef  identifier" directive was encountered, but there were
    additional tokens on the  line  to  the  right  of  "identifier".
    These extraneous tokens have been ignored.

E, 5004, "unexpected token(s) on #ifndef line ignored"

    A  "#ifndef identifier" directive was encountered, but there were
    additional tokens on the  line  to  the  right  of  "identifier".
    These extraneous tokens have been ignored.

E, 5005, "neither <...> nor "..." style include found"

    A "#include ...." directive was encountered.  Unfortunately, even
    after macro expanding the token list (if any)  that  was  on  the
    line, the token sequence did not combine to form any known format
    for an include file name.  The directive has been ignored.

W, 5006, "cannot change 'fatal' default diagnostic level"

    The "#pragma diagnostic_adjust ..." pragma was supplied,  but  an
    attempt  was  made  to  change  all  diagnostics  with  a default
    severity level of Fatal  to  something  else.   Diagnostics  with
    default  severity  of  fatal  cannot  be adjusted, and hence this
    pragma is not valid as far as  JRCPP  is  concerned,  and  it  is
    passed unchanged to the preprocessed output file.

H, 5007, "diagnostic display may be diminished"

    The  user  has  elected  to adjust some diagnostic level in a way
    that may reduce the amount  of  diagnostic  information  that  is
    produced.  The  user should be wary that errors may be identified
    but not revealed, or severe errors may be downgraded to warnings,
    and an output file may still be produced.

E, 5008, "only one ancestral path selection is allowed"

    The directive "#pragma include_search ..." was provided, but more
    than    one    of    the    3    mutually    exclusive    options
    "only_eldest_ancestor",       "only_youngest_ancestor",       and
    "all_ancestors" was specified.  The later option was ignored, and
    the  first  ancestral option will be acted on (assuming there are
    no other syntax errors).

H, 5009, "non-ANSI C behavior requested"

    The #pragma  undefine_macros  has  requested  that  the  internal
    definitions  of  __FILE__,  __LINE__,  __DATE__,  and __TIME__ be
    removed from the the database.  This leaves open the  option  for
    notably  non-ANSI  behavior,  as any and all of these identifiers
    may now be redefined. Although this option  is  in  violation  of
    ANSI,  utilizing  it  provides  an  easy method of falsifying the
    value of __DATE__ and __TIME__ in order to  produce  a  mis-dated
    compilation.

H, 5010, "non-ANSI C behavior requested"

    The  #pragma  undefine_macros  has  requested  that  the internal
    definitions of __STDC__ be removed from the the  database.   This
    leaves  open  the  option  for notably non-ANSI behavior, as this
    identifier may now be  redefined.  Although  this  option  is  in
    violation  of  ANSI,  it  provides  a simple method of creating a
    preprocessor that can be used with  a  non-ANSI  compiler.   This
    simulation  often  assists  in  porting  code  that  has built in
    dependency on the value of __STDC__ in hopes of easing a port.

H, 5011, "non-ANSI C behavior requested"

    The directive "#pragma cplusplus_mode" was encountered.   One  of
    the  results  of  this  pragma is that __STDC__ is undefined, and
    made available for redefinition (note that __cplusplus takes  its
    place).   Since this option removes an "unremovable" aspect of an
    ANSI C preprocessor, the performance is clearly  non-ANSI.   Also
    note  that  //  style  comments  are  being  supported, which may
    further violate ANSI C behavior.

H, 5012, "non-ANSI C behavior requested"

    The directive "#pragma cplusplus_comment  ..."  was  encountered.
    The  //  style  comments  are being supported as a consequence of
    this pragma, and hence ANSI C compatibility cannot be guaranteed.

H, 5013, "non-ANSI C behavior requested"

    The  directive  "#pragma  space_between_tokens  ..."   has   been
    observed,   and   as   a   result,  additional  spaces  will  not
    automatically be added to the output file.   The  consequence  of
    this  omission  is  that  certain token pairs may, if they do not
    already have  white  space  separation,  "flow  together".   This
    result  is  occasionally  desirable  when  attempting to simulate
    certain aspects of a classical C preprocessor (re:  the  Reismann
    model).   This  flowing  together  of  tokens may cause effective
    pasting of consecutive tokens, and  a  net  effect  of  providing
    non-ANSI C compliant preprocessing.




F, 6001, "lexical scanner reading source: ...message..."

    This  diagnostic  is  always  produced in conjunction with a more
    detailed error 'message'.  This 'message' is usually "flex  input
    buffer  overflowed".   If  any  other  'message' is produced as a
    refinement  of  this  diagnostic,  it  should  be  considered  an
    internal compiler error, and the software manufacturer or support
    agency should be consulted.   The  typical  message  "flex  input
    buffer  overflowed"  indicates that an attempt was made to form a
    token that was larger than a hard wired static buffer (currently,
    511  characters).   Although  this  message  can  be generated by
    providing a single token (such as an  identifier  name)  that  is
    longer  than  511  characters,  there  is  a  more  likely  cause
    involving comments.   Comments  are  broken  into  "pieces"  that
    correspond   to   "logical   lines".    A  logical  line  is  the
    concatenation of a  series  of  physical  lines  accomplished  by
    placing  backslash  ("\")  characters  at the end of lines.  This
    practice of concatenating lines is most common  when  defining  a
    long  and complex macro. If, for example, such a macro definition
    exceeded 511 characters, AND an attempt was made to  comment  out
    the  macro  by  enclosing it in comment delimiters "/*" and "*/",
    then this message would be produced.  The  work  around  in  this
    "most common" of these "extremely rare" cases is to use enclosing
    "#if 0" and "#endif"  to  remove  the  code  from  consideration,
    rather  than  using  comment delimiters.  Note that this is NOT a
    problem that occurs when comments are simply long,  as  they  are
    then  considered  to  be  a series of "comment segments", each of
    which corresponds to a physical line,  which  is  generally  much
    less than 512 characters in length.  Note also that with features
    provided in ANSI C involving the placement of consecutive  string
    literals,  and  the  interpretation  of such sequences, it is not
    necessary to have string literals that are over 511 characters in
    length  (including the delimiting quotes).  See BUGS/FEATURES for
    additional comments.

F, 6002, "lexical scanner reading pasted text: ...message..."

    This diagnostic is always produced in  conjunction  with  a  more
    detailed   'message'   (depending   on  the  problem).   If  this
    diagnostic is  produced  it  should  be  considered  an  internal
    compiler  error,  and the software manufacturer or support agency
    should be consulted.

F, 6003, "preprocessing token parser error: yacc stack overflow"

    This message indicates that the level of nesting of  preprocessor
    if  directives  is too large for the current parser.  The current
    limit is at least 50 levels of if directives deep, and this limit
    is  only  significant  if  all the nested if statements have both
    "#elif" and "#else" sections, AND the nesting is through the else
    clauses.   As  a  practical  matter,  this  limit should be of no
    importance to a user.  See BUGS/FEATURES for more details.

E, 6004, "#if/elif evaluated false due to: yacc stack overflow"

    This message indicates that the level of  nesting  complexity  of
    the  expression  provided in a "#if" or "#elif" directive exceeds
    about 75 levels of parenthesis, or  about  30  levels  of  nested
    conditional   expressions  (re:  the  ternary  operator  sequence
    "a?b:c").  This should be of little consequence to  a  user,  but
    see BUGS/FEATURES for more details.


F, 6005, "out of memory. Object requested was ..."

    The  preprocessor  was  unable  to  allocate  any more memory for
    preprocessing.  This error is most  common  under  MSDOS.   While
    running  in MSDOS, be sure that you are not running in a "command
    shell" underneath a program that is using up a  lot  of  physical
    memory   (some   "make"   utilities  demonstrate  this  "hoggish"
    feature).  Also under MSDOS, if you have  not  already  done  so,
    purchasing  and  installing  additional  memory,  up  to the full
    640KByte limit, can often prevent this diagnostic.  This  problem
    can  be  reduced  (and often removed) under MSDOS by reducing the
    number of TSR (Terminate and Stay Resident)  programs  that  have
    been  installed.   On  virtual  memory  systems, such as OS/2 and
    UNIX, this error should only occur if  virtual  memory  has  been
    exhausted  by filling all available swap space available on disk.
    Solutions to this problem in  a  virtual  memory  system  include
    purchasing additional physical memory (i.e., RAM), and purchasing
    or enlarging the available swap space (i.e., get a  bigger  disk,
    and/or  set  up  the swap area on a partition with more available
    space).


F, 6006, "out of memory during character pool reallocation"

    JRCPP exhausted available memory.  This problem occurred  when  a
    new  heap  (character  pool) was being created to hold additional
    strings of text (generally, the spellings of tokens).

F, 6007, "out of memory during concatenation operation"

    JRCPP exhausted available memory.  This problem occurred when two
    tokens strings were being concatenated, and a working area needed
    to be allocated.

F, 6008, "out of memory during stringize operation"

    JRCPP exhausted available memory.  This problem occurred  when  a
    token's  spelling  was  being "stringized" (enclosed in quotes as
    requested by the # operator), and a working  area  needed  to  be
    allocated.

F, 6009, "out of memory while unquoting file name"

    JRCPP  exhausted  available memory.  This problem occurred when a
    file name provided in an #line directive had to be extracted, and
    a working area needed to be allocated.

F, 6010, "out of memory while extracting name in include directive"

    JRCPP  exhausted  available memory.  This problem occurred when a
    file name provided in an #include directive had to  be  extracted
    from the surrounding quotes or angle brackets, and a working area
    needed to be allocated.

F, 6011, "out of memory while extracting directory prefix"

    JRCPP exhausted available memory.  This  problem  occurred  while
    processing  a  #include  directive.   The  path  prefix was being
    extracted from some ancestral include file, and  a  working  area
    needed to be allocated.

E, 6012, "#if/elif evaluated false due to division by zero"

    The  evaluation  of  the  token  sequence  on a #if or #elif line
    required a division by an expression that evaluated to zero.  The
    evaluator  has  abandoned  examination of the expression, and has
    supplied a default (error recovery) evaluation of FALSE.


E, 6013, "#if/elif evaluated false due to modulus of zero"

    The evaluation of the token sequence  on  a  #if  or  #elif  line
    required  taking  the  modulus by an expression that evaluated to
    zero (example: 4 % 0). The evaluator has abandoned examination of
    the  expression,  and  has  supplied  a  default (error recovery)
    evaluation of FALSE.