Conference vaxaxp::vmsnotes

    I'm amazed by this one...
    
    When the STARLET-for-C work was done originally in V1.0 of Alpha, I
    added a hack to the SDL sources that let the H files be post-processed
    so that the NAM pointer in FAB, FAB pointer in RAB, etc., were all
    defined to be of the correct type.
    
    Now for some reason, I didn't do this to the XAB pointers. What I can't
    remember is whether there was a reason not to do them or if this was an
    oversight.
    
    The snag is, we may not now be able to change them because of the
    "existing code out there relying on it the way it is today" issue,
    i.e. you may simply have to live with it. And I'm not being flippant
    and devaluing your concern - we've unfortunately had to close some
    similar QARs this way already.
    
    - Richard.

    Would our official response be to type cast RMS structure pointer
    types (those currently defined as CHAR *) using (CHAR *)?  Can we 
    document this for OpenVMS Alpha (at least the release notes)?
    
    Finally, if the change would break existing code I agree that we
    need leave it as is even if it is not politically correct, but we
    do need to document the behavior.
    
    Thank you, -drew

   Use (void *), not (char *).  The former is the official "shut up and
   just it" C syntax.

   Richard, I'd suspect you cannot tell *which* XAB is hanging off that...

    I'll raise a formal IPMT SPR, but we really need to reconsider and
    make the appropriate changes.  The customer was not amused that we
    did not want the make the header file(s) ANSI-C compliant (at least
    compatible between VAX and Alpha).
    
    We can not find a case whereby someone using the current (char *)
    on OpenVMS Alpha would break if we changed the definition to
    (void *).
    
    -drew

    Here is the official esculation.  It has been raised as priority 3
    and I hope we do the right thing.  -drew
    
    
VERSION INFORMATION:

Product: DEC C
Product/Component Version(s): 5.5
Operating System Version(s):  OpenVMS Alpha V6.1, V6.2, V7.0, V7.1

SOURCE: (do not enter - for STARS purposes only)


SYMPTOM:

Header files are inconsistent between OpenVMS Alpha and VAX making it
difficult to write portable code between the environments.

Specifically RMS header files include an incorrect definition on OpenVMS
Alpha where pointers to structures are represented using character
pointer types.  The result is a compilation error:

  %CC-W-PTRMISMATCH, In this statement, the referenced type of the
   pointer value "&xab" is "pointer to struct xabdef", which is not
   compatible with "char".


DIGITAL RESPONSE:

This problem has been reported to Engineering.


WORKAROUND:

Type cast RMS structures using (void *) to avoid any compilation
errors or use CC/STANDARD=VAXC to relax the ANSI standard.


ANALYSIS:

The following RMS fields which are used to point to structures are
not properly defined on OpenVMS Alpha, they include:

  fab$l_xab
  rab$l_xab
  xab$l_nxt
  xab$l_itemlist
  xab$l_itmlst

Currently these are defined as character pointer types (char *) when
they actually are used to point to structures; therefore the correct
definition would be a generic pointer type (void *).

The following example, when compiled on OpenVMS Alpha, will generate
compiler warnings:

#include <rms.h>
#include <stdlib.h>

static struct FAB *fab;
static struct RAB *rab;
static struct XAB *xab;

main()
{
   fab = malloc ( sizeof ( struct FAB ) );
   rab = malloc ( sizeof ( struct RAB ) );
   xab = malloc ( sizeof ( struct XAB ) );

   *fab = cc$rms_fab;                /* Initialize the FAB         */
   fab->fab$l_xab = &xab;            /* Address of XAB structure   */

   *rab = cc$rms_rab;                /*Initialize the rab          */
   rab->rab$l_xab = &xab;            /* Address of XAB structure   */
}

In this particular case you can make to following modifications to
correct this problem:

   fab->fab$l_xab = (void *) &xab;   /* Address of XAB structure   */
   rab->rab$l_xab = (void *) &xab;   /* Address of XAB structure   */
\
\
\ BUSINESS IMPACT:
\
\ Makes it difficult to create code which is portable between OpenVMS VAX
\ and Alpha.  This type of problem can generate necessary calls to the
\ customer support center.
\
\
\ CONFIGURATION:
\
\ System Type:  N/A
\ Option Type:  N/A
\ Memory Size:  N/A
\ Installed Patches: N/A
\ Part Numbers:  N/A
\ Revision Levels: N/A
\
\   Note:  Upon Product Engineering's request, retain failed parts for
\          engineering analysis and problem isolation.
\
\ If the problem is not clearly defined to the hardware/software component
\ and cause, then complete the following:
\
\  o For a network problem, prepare a "complete" network map to be made
\    available to Product Engineering. Examples of Eng Grps:IBM-Interconnect,
\    Pathworks, Networks
\  o For a cluster problem, prepare a "complete" cluster diagram to be made
\    available to Product Engineering.
\  o Prepare a "complete" listing of all third party/Digital products.
\
\
\ CHANGES TO ENVIRONMENT:
\
\ N/A
\
\
\ TESTING INFORMATION:
\
\ Has this issue been reproduced on CSC lab systems? Y
\     Explain: XWINGS:: (OpenVMS Alpha V6.2), CSC64:: (OpenVMS Alpha
\     V7.1)
\
\ Is this issue consistently reproducible at the customer site? Y
\     Explain: Anytime
\
\ Include the exact steps to reproduce the behavior, including any
\ programs, if the information is not already included above.
\
\     See example above.
\
\ If the problem involves a system crash, include the crash analysis here.
\
\     N/A
\
\ Network location of logfiles, crash dump, and all supporting files:
\
\     N/A
\
\ Engineering notes conference
\
\     VAXAXP::VMSNOTES.NOTE, note 124.*

re .4

>    We can not find a case whereby someone using the current (char *)
>    on OpenVMS Alpha would break if we changed the definition to
>    (void *).

    If someone were dereferencing without type casting then I think the
    proposed change would be visible. Since the first field of all user
    RMS structures is a byte such usage would be vaguely valid. Something like

    /* what kind of XAB is the FAB pointing at */
    switch ( *fab.fab$l_xab )
    {
        :
        :
        :
    }

    re: .6
    
    Excellent.  Given that I would agree it would be difficult to change
    behavior.  How will we respond to the developer migrating this same
    code back to OpenVMS VAX as it will fail to compile giving an error:
    
                 switch (*fab->fab$l_xab)
              ...........^
      %CC-E-NEEDNONVOID, In this statement, "*fab->fab$l_xab" has void
      type, but occurs in a context that requires a non-void result.
    
    The only ones we affect are those writing OpenVMS Alpha code only.
    
    I will still raise the SPR giving your example as a possible side
    affect to making the change.
    
    At this point I don't see us changing the behavior, I did contact
    the customer and he was pleased that we did find a valid condition
    which would break existing code.  He can see the bind we are in and
    did not push the issue.
    
    Thank you for the excellent analysis.  -drew

VERSION INFORMATION:

Product: DEC C
Product/Component Version(s): 5.5
Operating System Version(s):  OpenVMS Alpha V6.1, V6.2, V7.0, V7.1

SOURCE: (do not enter - for STARS purposes only)


SYMPTOM:

Header files are inconsistent between OpenVMS Alpha and VAX making
it difficult to write portable code between the environments.

Specifically RMS header files include an incorrect definition on
OpenVMS Alpha where pointers to structures are represented using
character pointer types.

The resulting compilation error using DEC C on OpenVMS Alpha:

  %CC-W-PTRMISMATCH, In this statement, the referenced type of the
  pointer value "xab" is "struct xabdef", which is not compatible
  with "char".

The resulting compilation error using DEC C on OpenVMS VAX:

  %CC-E-NEEDNONVOID, In this statement, "*fab->fab$l_xab" has void
  type, but occurs in a context that requires a non-void result.


DIGITAL RESPONSE:

This problem has been reported to Engineering.


WORKAROUND:

Type cast RMS structures, those defined as character pointers on OpenVMS
Alpha, using (void *) to avoid any compilation errors or use
CC/STANDARD=VAXC to relax the ANSI standard.

Type cast RMS structures, those defined as void pointers on OpenVMS VAX,
using the appropriate structure or field to avoid any compilation errors.


ANALYSIS:

The following RMS fields which are used to point to structures are not
properly defined on OpenVMS Alpha, they include:

  fab$l_xab
  rab$l_xab
  xab$l_nxt
  xab$l_itemlist
  xab$l_itmlst

Currently these are defined as character pointer types (char *) when
they actually are used to point to structures; therefore the correct
definition would be a generic pointer type (void *).

The following example, when compiled on OpenVMS Alpha, will generate
a PTRMISMATCH compiler warning.  The same example, when compiled on
OpenVMS VAX, will generate a NEEDNONVOID compiler warning.

#include <rms.h>
#include <stdlib.h>
#include <stdio.h>

static struct FAB *fab;
static struct RAB *rab;
static struct XAB *xab;

main()
{
   fab = malloc ( sizeof ( struct FAB ) );
   rab = malloc ( sizeof ( struct RAB ) );
   xab = malloc ( sizeof ( struct XAB ) );

   *fab = cc$rms_fab;                /* Initialize the FAB         */
   fab->fab$l_xab = xab;             /* Address of XAB structure   */

   *rab = cc$rms_rab;                /* Initialize the rab         */
   rab->rab$l_xab = xab;             /* Address of XAB structure   */

   xab->xab$b_cod = XAB$C_DAT;       /* Date and Time XAB          */

/* Determine type of XAB we are reading, XAB$B_COD                 */
   switch ( *fab->fab$l_xab )
   {
       case XAB$C_ALL : printf("XAB$C_ALL\n"); break;
       case XAB$C_DAT : printf("XAB$C_DAT\n"); break;
       case XAB$C_FHC : printf("XAB$C_FHC\n"); break;
       case XAB$C_ITM : printf("XAB$C_ITM\n"); break;
       case XAB$C_JNL : printf("XAB$C_JNL\n"); break;
       case XAB$C_KEY : printf("XAB$C_KEY\n"); break;
       case XAB$C_PRO : printf("XAB$C_PRO\n"); break;
       case XAB$C_RDT : printf("XAB$C_RDT\n"); break;
       case XAB$C_SUM : printf("XAB$C_SUM\n"); break;
       case XAB$C_TRM : printf("XAB$C_TRM\n"); break;
       default        : printf("*fab->fab$l_xab=%d\n", *fab->fab$l_xab);
   }
}

In order to modify this example to compile correctly on both OpenVMS
VAX and OpenVMS Alpha you need to type cast the pointer and refer to
the appropriate field in the XAB.  For example:

#include <rms.h>
#include <stdlib.h>
#include <stdio.h>

static struct FAB *fab;
static struct RAB *rab;
static struct XAB *xab;

main()
{
   fab = malloc ( sizeof ( struct FAB ) );
   rab = malloc ( sizeof ( struct RAB ) );
   xab = malloc ( sizeof ( struct XAB ) );

   *fab = cc$rms_fab;                /* Initialize the FAB         */
   fab->fab$l_xab = (void *) xab;    /* Address of XAB structure   */

   *rab = cc$rms_rab;                /* Initialize the rab         */
   rab->rab$l_xab = (void *) xab;    /* Address of XAB structure   */

   xab->xab$b_cod = XAB$C_DAT;       /* Date and Time XAB          */

/* Determine type of XAB we are reading, XAB$B_COD                 */
   switch ( ((struct XAB *)fab->fab$l_xab)->xab$b_cod )
   {
       case XAB$C_ALL : printf("XAB$C_ALL\n"); break;
       case XAB$C_DAT : printf("XAB$C_DAT\n"); break;
       case XAB$C_FHC : printf("XAB$C_FHC\n"); break;
       case XAB$C_ITM : printf("XAB$C_ITM\n"); break;
       case XAB$C_JNL : printf("XAB$C_JNL\n"); break;
       case XAB$C_KEY : printf("XAB$C_KEY\n"); break;
       case XAB$C_PRO : printf("XAB$C_PRO\n"); break;
       case XAB$C_RDT : printf("XAB$C_RDT\n"); break;
       case XAB$C_SUM : printf("XAB$C_SUM\n"); break;
       case XAB$C_TRM : printf("XAB$C_TRM\n"); break;
       default        : printf(
            "((struct XAB *)fab->fab$l_xab)->xab$b_cod=%d\n",
             ((struct XAB *)fab->fab$l_xab)->xab$b_cod );
   }
}

\
\
\ BUSINESS IMPACT:
\
\ Makes it difficult to create code which is portable between OpenVMS VAX
\ and Alpha.  This type of problem can generate necessary calls to the
\ customer support center.
\
\ It may be difficult to change the header file as it could break existing
\ code, but anyone using *fab->fab$l_xab is relying on compiler behavior
\ and the correct coding practice is to specify the field name.  See
\ analysis section for more details.
\
\
\ CONFIGURATION:
\
\ System Type:  N/A
\ Option Type:  N/A
\ Memory Size:  N/A
\ Installed Patches: N/A
\ Part Numbers:  N/A
\ Revision Levels: N/A
\
\   Note:  Upon Product Engineering's request, retain failed parts for
\          engineering analysis and problem isolation.
\
\ If the problem is not clearly defined to the hardware/software component
\ and cause, then complete the following:
\
\  o For a network problem, prepare a "complete" network map to be made
\    available to Product Engineering. Examples of Eng Grps:IBM-Interconnect,
\    Pathworks, Networks
\  o For a cluster problem, prepare a "complete" cluster diagram to be made
\    available to Product Engineering.
\  o Prepare a "complete" listing of all third party/Digital products.
\
\
\ CHANGES TO ENVIRONMENT:
\
\ N/A
\
\
\ TESTING INFORMATION:
\
\ Has this issue been reproduced on CSC lab systems? Y
\     Explain: XWINGS:: (OpenVMS Alpha V6.2), CSC64:: (OpenVMS Alpha
\     V7.1)
\
\ Is this issue consistently reproducible at the customer site? Y
\     Explain: Anytime
\
\ Include the exact steps to reproduce the behavior, including any
\ programs, if the information is not already included above.
\
\     See example above.
\
\ If the problem involves a system crash, include the crash analysis here.
\
\     N/A
\
\ Network location of logfiles, crash dump, and all supporting files:
\
\     N/A
\
\ Engineering notes conference
\
\     VAXAXP::VMSNOTES.NOTE, note 124.*