Conference turris::decc

  Check if FALSE, TRUE are already defined. For example, from <stdio.h>:

/*
**  DEC C RTL extension.  Define the values TRUE and FALSE.
*/
#ifndef _ANSI_C_SOURCE
#   ifndef TRUE
#      define TRUE 1
#   endif
#   ifndef FALSE
#      define FALSE 0
#   endif
#endif

I ran into this exact problem while compiling some code that works fine on
Microsoft and other UNIX vendors. The workaround (as suggested in .1) is to add
-D_ANSI_C_SOURCE to the command line. The problem(?) is within stdio.h.

I am not sure I agree with having to add -D_ANSI_C_SOURCE to the command line to
eliminate "namespace pollution" when #including the "standard" header files.
This is just another issue that developers face when porting applications from
elsewhere to Digital UNIX.

Fwiw, I was able to get lint to crash with my simple test program (due to the
enum "syntax error"). I have reported that and it will be fixed in Steel (the
next major release after Digital UNIX V4.0).

If others agree that the standard header "namespace pollution" is an issue that
needs to be addressed in this case, I'd be happy to report an OSF_QAR against
the offending header file.

-Jeff

  On OpenVMS the only offending standard header (as far as the TRUE and FALSE
  identifiers are concerned :-) is <stdio.h>.

  I'm not sure, that this is a bug because these identifiers are hidden in a 
  strict ANSI mode or when any of _ANSI_C_SOURCE, _XOPEN_SOURCE,
  _POSIX_C_SOURCE or _XOPEN_SOURCE_EXTENDED is defined.

  I think, this is a matter of the default compiler mode. Since the default on
  OpenVMS is /STANDARD=RELAXED_ANSI89 where TRUE and FALSE are visible, I
  think, that we should remove them from the header.

  Generally speaking, it seems to me, that in a standard header we shouldn't
  declare identifiers which is not reserved for the use by the implementation
  by any standard even if they are invisible in a ANSI/XOPEN/POSIX mode.

  Boris

    re .3;
    
    Removing these definitions will, of course, break a lot of existing C
    code on VMS, where people have come to rely on them. 
    
    \dave
    

>     Removing these definitions will, of course, break a lot of existing C
>     code on VMS, where people have come to rely on them. 

    Some people obviously will have to define TRUE and FALSE in their sources
    if the header will change. On the other hand, one won't need to change an
    ANSI-compliant code from another vendor referencing these identifiers in
    order to have clean compilation in the default compiler mode.

    Boris

Great ! compiling with -D_ANSI_C_SOURCE solved the
invalid enumerator problem.

I get now the following fault on this code 
- that in the mind of the customer is meant to exercise
the compiler ...

cc: Error: /space/tuebingen/num/15/gax.c, line 167: In this statement, "Fields"
is not declared.
  Fields = (IntInfo **)vmalloc(vmblock, VVEKTOR,

where :

   167    Fields = (IntInfo **)vmalloc(vmblock, VVEKTOR,
   168                                 Maximum, sizeof(*Fields));
   169    if (! vmcomplete(vmblock))
   170      return 8;

etc.

Have a look at your source, it should be declared somewhere. Or even better
look at a compiler generated source listing.  VMS people do that, they let
the compiler generate a listing with all the source lines all the include
files and all the macro expansions. Then they load it into an appropriate
editor and look for definitions, declarations conditionals etc. You can do
that with decc aka -migrate: -source_listing -show all         

Hope this helps,
Hartmut

OK.  The compiler group will assume that your missing Fields declaration
is a user error which you will fix unless we hear otherwise.

My favorite way of looking at these things is to add -E > gax.preproc
to my compile command line and then to edit the preprocessor output
next to the source.  I can usually then tell what's up.
-source_listing -show all is equivalent, but I'm not fond of 132 column
listing files.

R.