Conference azur::mcc

    Function prototypes are not portable to the Ultrix C compilers we are
    using at the moment.   At such time when we move over to the "DEC" ANSI
    C compiler, we will consider adding function prototypes, but at the
    moment we'd just wind up have to conditionalize them.

>> Function prototypes are not portable to the Ultrix C compilers we are
>> using at the moment.   At such time when we move over to the "DEC" ANSI
>> C compiler, we will consider adding function prototypes, but at the
>> moment we'd just wind up have to conditionalize them.

It would be very helpful to the developers currently writing Access Modules
under VMS to have the prototypes -- if the MCC_INTERFACE_DEF must have
an #ifdef VMS -- then so be it.

Doesn't make much sense to exclude something as useful as function prototypes
just because Ultrix doesn't support it!

/keith

Re: Keith's reply

I second the motion...  The potential usefulness of the function prototypes
far outweighs the disadvantage that they're not yet supported by ULTRIX.  I
suspect that a lot of debugging time would have been saved if the
prototypes were used right from the start.

Roy

    I don't buy it.  One of the costs of portability is not being able
    to do things ideally everywhere in exchange for a wider market. 
    
    #ifdefs are to be avoided if possible - it just makes the code hard
    to maintain.
    
    But as I said, this is a moot point.  ANSI C will be here within a year
    and we can function prototype everything.
    
    
    As a side issue, once we implement function prototypes, I'd like to
    see the parameter validation code in the mcc public calls be reduced
    somewhat.  Compiletime checking of parameters sure beats the
    performance hit we take at runtime by revalidating parameters on
    debugged code 100's of times per second.
    
    

>    But as I said, this is a moot point.  ANSI C will be here within a year
>    and we can function prototype everything.

Remember V1.0 of VAX/C? That's not a dig against the DEC/C developers. But
compilers are complex beasts, and the first versions can be frustrating
to build your products with. I think you should view the move from VAX/C
as farther out than FRS of DEC/C.

But let's ignore that issue for the moment. I'm writing code against
the DECmcc libraries today. Our coding standards (and common sense)
require function prototypes. I think (probably naively) that an .H
file could be written containing function prototypes for the MCC
kernel shared image. I could include that file into my programs and
have my calls checked at compile time. Would the compilation of my
sources know that the sources of the kernel routines weren't defined
with function prototypes? Would the run-time binding and execution of those
calls? Nah.

How about you leave the sources for the MCC kernel (and DESFRAME) alone,
but just create .H files for them with function prototypes? A small
matter of a TECO macro (I jest, it has been too many years...).

>> How about you leave the sources for the MCC kernel (and DESFRAME) alone,
>> but just create .H files for them with function prototypes? A small
>> matter of a TECO macro (I jest, it has been too many years...).

Either ...

(1) The Function Prototypes should go into MCC_INTERFACE_DEF.H with the

	#ifdef VMS
	 :
	#endif

    around them ... or

(2) into a seperate .H file (MCC_FUNC_PROTOTYPES.H ??)


I would prefer #1 --- that way I wouldn't have to change any existing code!


/Keith

I tried it with MCC_DESFRAME.H since the OLB only has 7 entry points. Since
support for prototypes may vary from compiler to compiler, I conditionalized
on the macro PROTOTYPES_SUPPORTED. Then I just define that appropriately.
Right now it is just

#define PROTOTYPES_SUPPORTED vaxc

Here's the prototypes:

extern MCC_T_MCCError mcc_desframe_init_alloc_list
    (
#ifdef PROTOTYPES_SUPPORTED
    char **alloc_mem_list          /* Pointer to Memory Management Service */
#endif
     );

extern MCC_T_MCCError mcc_desframe_alloc
    (
#ifdef PROTOTYPES_SUPPORTED
     char **pp_alloc_mem_list,     /* Pointer to Memory Management Service */
     char **p_buffer,              /* Pointer to the buffer */
     MCC_T_UNSLONG *p_byte_count   /* Pointer to the allocation byte count */
#endif
     );

extern MCC_T_MCCError mcc_desframe_free_alloc_list
    (
#ifdef PROTOTYPES_SUPPORTED
     char **alloc_mem_list          /* Pointer to Memory Management Service */
#endif
     );

extern MCC_T_UNSLONG mcc_desframe_create_descriptor
    (
#ifdef PROTOTYPES_SUPPORTED
     char **alloc_mem_list,         /* Address of allocation memory service */
     char **desc,                   /* Address of an MCC_T_Descriptor */
     MCC_T_UNSSHORT *length,        /* Address of number of bytes in buffer */
     MCC_T_UNSLONG *datatype,       /* Address of the descriptor datatype */
     char *value,                   /* Address of the value to copy */
     MCC_T_IDCode *id,              /* Address of the descriptor id */
     MCC_T_IDCode *vmsdatatype      /* Addr of VMS datatype for descriptor */
#endif
     );

extern MCC_T_UNSLONG mcc_desframe_set_cvr_and_reply
    (
#ifdef PROTOTYPES_SUPPORTED
     dt_callargs *pCallArgs,        /* Pointer to CallArgs structure */
     dt_comm_local_context *ppLC,   /* Pointer to Local Context Block */
     MCC_T_UNSLONG **cvr            /* Return CVR */
#endif
     );

extern MCC_T_UNSLONG mcc_desframe_append_error
    (
#ifdef PROTOTYPES_SUPPORTED
     char **alloc_mem_list,         /* Address of memory allocation service */
     MCC_T_Descriptor **error_stack,/* Address of an MCC_R_Descriptor */
     MCC_T_UNSSHORT *error_status,  /* Address of the error value */
     MCC_T_UNSLONG *datatype,       /* Addr of the error descriptor datatype */
     MCC_T_IDCode *arg_id,          /* Addr of the error descriptor id */
     MCC_T_IDCode *vmsdatatype      /* Addr of VMS datatype for descriptor */
#endif
     );

extern MCC_T_UNSLONG mcc_desframe_validate_callargs
    (
#ifdef PROTOTYPES_SUPPORTED
     dt_callargs *pCallArgs,             /* Addr of call arguments structure */
     dt_valid_callargs *p_ValidCallArgs, /* Addr of static validation tables */
     dt_comm_local_context **ppContext   /* Addr of the common local context */
#endif
     );

extern MCC_T_MCCError mcc_desframe_package_call_args
    (
#ifdef PROTOTYPES_SUPPORTED
     MCC_T_IDCode *verb,      /* coded value of directive to be performed */
     MCC_A_AES *entity,       /* entity to which directive applies */
     MCC_T_IDCode *attribute, /* Attribute to which directive applies */
     MCC_A_TIMEFRAME *time_spec, /* time spec used to control directive */
     MCC_T_Descriptor *in_q,  /* optional qualifier input ILV */
     MCC_T_Descriptor *in_p,  /* optional params input ILV */
     MCC_A_HANDLE handle,     /* Context info used for multiple responses */
     MCC_A_AES *out_entity,   /* optional ILV to describe instance */
     MCC_T_Descriptor *time_stamp, /* Time when service was performed */
     MCC_T_Descriptor *out_p, /* Output data in ILV */
     MCC_T_Descriptor *out_q, /* reserved for future use */
     dt_callargs *CallArgs    /* Address of CallArgs structure */
#endif
     );

The header file for the DNS portable clerk interface routines
has another good example of conditional code for functional prototypes.
The file is /usr/include/dnsclerk.h on ULTRIX systems with phase V
installed (the copy on minion::"/usr/include/dnsclerk.h" is world
readable at the moment, for anyone who wants to take a peek).

RE: .8

The way dnsclerk.h does it is cleaner, gets the conditionals out of
sight better.

Yes .. the way DNSCLERK.H implements Function Prototypes is the way to go;
Good job to the DNS folks!

With regards to: DECmcc, Function Prototypes, and V1.1 ... We are currently
working on the EFT-1.1 kit.  There is no time in the schedule to add and TEST
Function Prototypes for the Common Routines or Design Framework (correct
me MR. Toolkit PL if I'm wrong on the Design Framework).

However - that is not to say that people working on DECmcc Access Modules
can not have Function Prototypes ... It just means they won't be in the
EFT-1.1 kit and supported by DECmcc Engineering.

Should anyone out there have the time to put together the Function Prototypes,
please post them in this note!  To use them, simply append them to the
SYS$LIBRARY:MCC_INTERFACE_DEF.H file.  In case you haven't seen the method
to create portable Function Prototypes (as found in DNSCLERK.H) ...

/Keith

  :
  :
  :


/*
 * Determine if prototypes are acceptable
 */

#ifdef  vaxc
#define PROTO_OK
#endif  /* vaxc */

#ifdef  msc
#define PROTO_OK
#endif  /* msc */

#ifdef  mips
#define PROTO_OK
#endif  /* mips */

#ifdef  PROTO_OK
#define _(X) X
#else   /* PROTO_OK */
#define _(X) ()
#endif  /* PROTO_OK */

#undef  PROTO_OK

/*
 * Now for the external definitions/prototypes
 */

int 
dnsAddAcc _((
    dns_opq_fname	*Name_p,
    enum dnsEntries	EntryType,
    dns_opq_fname	*PrincipalGroup_p,
    int 		AceRights,
    int 		AceFlags,
    struct dnsFlagStat	*Flags_p));

  :
  :
  :

    no you didn't miss it. the entry points are described in the SRM
    for the kernel. For more information on the frame work send mail
    to took::d_black (darryl) he should be able to help you.
    
    All MCC entry points are defined in a vector file which you link
    against (kernel_shr), this is done so that changes to the list of
    routines does not require a relink.
    
    

RE: .11


>    no you didn't miss it. the entry points are described in the SRM
>    for the kernel. For more information on the frame work send mail
>    to took::d_black (darryl) he should be able to help you.
>    
>    All MCC entry points are defined in a vector file which you link
>    against (kernel_shr), this is done so that changes to the list of
>    routines does not require a relink.


Jill - which note were you replying to?

/keith

    
    don't ask me, I read so many yesterday, I remember the question
    I was answering...but it has nothing to do with the note I placed
    it against.
    
    I know they let me come back to work physically, but mentally I
    think the vote is still out....
    
    I will try to find the note I was answering and move the response.
    Sorry about that. Just don't throw things at me, unless of course
    they are doritos.
    

    
    Ahh!  So that's why the machines are always out of Doritos around here!
    
    Fred