Article 170259 of comp.os.vms:
Some thoughts on DEC C, standards, defines, functions, and so forth.

In DEC C there is

 /standard=[ANSI89,VAXC,RELAXED,PORTABLE,COMMON,RELAXED_ANSI89]

to set the standard.  But really that doesn't do it, you have mess around
with other defines to pick up other functions, ie:

  _XOPEN_SOURCE_EXTENDED  (or _XOPEN_SOURCE)
  _POSIX_C_SOURCE
  __HIDE_FORBIDDEN_NAMES
  _VMS_CURSES
  _BSD44_CURSES

In fact, the only way I've ever found to figure out what you need for a
given function, and sometimes to even find out if a given function exists,
is to dump a copy of DECC$RTLDEF.TLB to text, and poke around in it with a
text editor.  That's crude, but at least you don't get into problems with
documentation being out of synch with the actual headers. 

Still, there are things I would really like to see changed around in DECC:

 1.  Provide a help file with a comprehensive list of functions and 
     constants, in alphabetical order, indicating which combinations of
     /standard and /define will allow a program to access that function. 
     This should be generated computationally directly from the header 
     files for each release (to avoid version mismatches).  Ie:

     $ HELP CC run div modes

         Standard         Define
         All              -

     $ HELP CC run popen modes

         Standard         Define
         All              __VMS_VER >= 70000000

     $ HELP CC constants M_PI modes
         Standard         Define
         !ANSI89          _XOPEN_SOURCE || !_DECC_V4_SOURCE

            
 2.  An additional define "_OPENVMS_RTL" which will enable the RTL extensions
     on some functions, but NOT turn off ANSI C otherwise.  Ie, 

       $ CC/standard=ansi89/prefix=all/define=_VMS_RTL

     would let you use the long form of fopen(), but still maintain ANSI89
     everywhere else.

     Alternatively, and actually I would have liked this solution better
     in the first place, everywhere that DEC C on OpenVMS is going to
     extend a standard function, have something like this:

       fopen      /* regular ANSI C fopen, and fopen is always ANSI C */
       fopen_vms  /* equivalent to the current nonANSI C version of fopen */

     where the *_vms functions are available in most /standard modes by 
     default, unless intentionally disabled. (Note
     that this is the route they took with "vfork", so the compiler is a bit
     inconsistent in this regard.)

     Either way, we'd still have constructs like these laying about:

     #ifdef __VMS
        fd = fopen("FILENAME","r","rat=cr", "rfm=var");
/* or     fd = fopen_vms("FILENAME","r","rat=cr", "rfm=var");   */
     #else
        fd = fopen("FILENAME","r");
     #endif
     
     This does not weaken the ANSI C conformance of the compiler, 
     probably it enhances it!  Currently if you want these RTL enhanced 
     functions you have to turn ANSI C off, which is a global sort of change,
     even if you use #pragma's around the one include in question.
     This new method just lets you pick up the *extra* pieces you want.
     In this sense it is much closer to the way the XPG4 pieces are 
     handled, in most cases those are *in addition* to ANSI C.

     One reason I prefer the _VMS form of the functions, is that it makes
     it very easy to figure out where you have messed up.  Preprocess with
     __VMS turned off and any _vms that remain in the resulting texts are
     mistakes.  Moreover, there isn't any question that the "fopen_vms()" is
     NOT the fopen(), something you can't tell from the first form, above,
     unless you also know what compiler flags have been set.  That is,
     if you stumble upon this, nowhere near an #ifdef __VMS

        fd = fopen("FILENAME","r","rat=cr", "rfm=var");
           
     it might be what the programmer did this on purpose (they
     want the RTL extended form), or it might be a mistake (they wanted the
     ANSI C form), it all depends upon the state of the compiler, 
     which you can't know from looking at the source code, whereas: 

        fd = fopen_vms("FILENAME","r","rat=cr", "rfm=var");

     is an explicit expression that this function is to be the _VMS 
     specific form.
  
     For purposes of backwards compatibilty one would need to replace the
     existing parts of the headers from this:

#ifdef _ANSI_C_SOURCE
    __FILE_ptr32 fopen   (const char *__filename, const char *__mode);
#else
    __FILE_ptr32 fopen   (const char *__filename, const char *__mode, ...);
#endif

     to this

#ifdef _ANSI_C_SOURCE && !_VMS_RTL
    __FILE_ptr32 fopen   (const char *__filename, const char *__mode);
#else
    __FILE_ptr32 fopen_vms   (const char *__filename, const char *__mode, ...);
#define fopen fopen_vms /* backwards compatibility */
#endif

Anyway, my two cents worth.

Regards,

David Mathog
mathog@seqaxp.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech 
**************************************************************************
*Affordable VMS? See:  http://seqaxp.bio.caltech.edu:8000/www/pcvms.html *
**************************************************************************