Conference turris::decc

2199.0. "Customer DECC Comments and Suggestions " by XDELTA::HOFFMAN (Steve, OpenVMS Engineering) Thu May 22 1997 11:43

Path:
pa.dec.com!decwrl!nntp.primenet.com!enews.sgi.com!news.mathworks.com!news-peer.sp
printlink.net!news.sprintlink.net!Sprint!howland.erols.net!newsfeed.internetmci.c
com!news.ridgecrest.ca.us!nntp-server.caltech.edu!seqaxp.bio.caltech.edu!MATHOG
From: [email protected]
Newsgroups: comp.os.vms
Subject: DEC C:  Defines, functions,etc.
Date: 21 May 1997 20:06:52 GMT
Organization: Biology Division, Caltech, Pasadena CA 91125
Lines: 129
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: seqaxp.bio.caltech.edu

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
[email protected]
Manager, sequence analysis facility, biology division, Caltech 
**************************************************************************
*Affordable VMS? See:  http://seqaxp.bio.caltech.edu:8000/www/pcvms.html *
**************************************************************************

Path:
pa.dec.com!news1.digital.com!su-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.c
com!news.bbnplanet.com!newsfeed.internetmci.com!news.ridgecrest.ca.us!nntp-server
r.caltech.edu!seqaxp.bio.caltech.edu!MATHOG
From: [email protected]
Newsgroups: comp.os.vms
Subject: mysterious DEC C message
Date: 20 May 1997 22:14:17 GMT
Organization: Biology Division, Caltech, Pasadena CA 91125
Lines: 50
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: seqaxp.bio.caltech.edu

Oh high gurus of mysterious compiler messages, please enlighten me!

DECC 5.5, OpenVMS 6.2, Software from Unix (not my code)

  $ mycc1 := cc/standard=ansi89/nolis/prefix=all -
    /include=[-...] -
    /define=(__ODD,_POSIX_C_SOURCE, SRSINCLUDE=""""""""srs5.h"""""""") -
    /warnings=(disable=dollarid)

  $ mycc1 [-.src]icaop.c
  int OddRegisterObj (SDLoOBJ *obj);
  ............................^
  Missing ")".
  at line number 68 in file SEQAXP$DKB400:[SHARED.PROGRAMS.SRS.SRC]ICAOP.C;9

  void OddIdRegister (SDLoOBJ *class, char *idName);
  ............................^
  Missing ")".
  at line number 69 in file SEQAXP$DKB400:[SHARED.PROGRAMS.SRS.SRC]ICAOP.C;9


etc. Many such warnings occur, all in the prototype statements that are
located after the #include statements, all SDLoOBJ * locations are affected.

The OddIdRegister function is from another module.  Here is SDLoOBJ:

#ifndef _SDLoOBJ
typedef struct SDLoOBJ *dummytointroducestructtagSDLoOBJ;
#endif

at least, I *think* that's where it's coming from, the #includes are a real 
zoo.

Here is the one place the function is used:

      OddRegisterObj ((struct SDLoOBJ *) tmp);

I tried compiling with /preprocess only, but the line generating the
warnings came back exactly as above.

Any ideas as to what might be going wrong here?

Thanks,

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

> In DEC C there is

(on UNIX) -std, -std1

> 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

This affects both C and C++ users; C++ users probably more than C.
I don't think there's a plan to change the header files (that I know of).

-Jeff

Re .1
The prototypes are using SDLoOBJ as if it's a type, but the definition shown:
	#ifndef _SDLoOBJ
	typedef struct SDLoOBJ *dummytointroducestructtagSDLoOBJ;
	#endif
doesn't define it as a type.  It defines it as a struct tag, and defines a
related name as a type.

Most likely there is something in the program's header files that makes them
want to tack on "dummytointroducestructtag" on the front of this name when
compiled with DEC C, but not with other compilers.

Anyway, when the compiler sees
	int OddRegisterObj (SDLoOBJ
where SDLoOBJ doesn't name a type, it assumes it must be declaring the name
of a formal parameter.  The next thing allowed would be "," or ")".