Conference turris::decc

  This is more of an OpenVMS question, as OpenVMS owns this header file.

>
>     A customer is not happy with the __NEW_STARLET symbol starting in OVMS
>     7.0 for the Alpha.  He wants to write code that will compile on the VAX
>     and ALPHA.  Will the __NEW_STARLET symbol be available on the VAX?
>     
>     The new starlet definitions for C are for the ALPHA only and are
>     documented in the OVMS 7.0 New Features Manual section 4.13.  
>     
>     I assume these new prototype definitions are for 64 bit int's and 64
>     bit pointers, which are not available for the VAX.  Is this why the
>     __NEW_STARLET symbol will not be defined for the VAX?
>     

  I think, the customer does not understand the usage of the __NEW_STARLET 
  macro and what this macro is good for. This macro is defined *manually*
  either in CC command line or in the source file before #inclusion of the
  <starlet.h> header to fetch prototypes of 64-bit system services which
  are not available on VAX and were not available on Alpha before OpenVMS
  Alpha V7.0. Note, that the "old style" declarations are retained in the
  header for compatibility and they are fetched if __NEW_STARLET is not
  defined.

  I don't see any reason to define __NEW_STARLET on the VAX.

  Boris

   I've got extensive amounts of C code that compiles on both platforms;
   NEW_STARLET controls the selection of an improved (and 64-bit-capable)
   set of prototypes and definitions.  And as .1 indicates, the new
   definitions must be explicitly requested -- as your customer wants
   compatible definitions, don't use __NEW_STARLET and don't use 64-bit
   addressing, or conditionalize it on the platform...

    Thanks for the information.  I'll pass it along to the customer.
    Sorry for not getting back sooner, I've been out on Vacation.
    
    Thanks,
    
    	Bob

I have a question regarding __NEW_STARLET and this appears to be as good a
place as any to ask.

When I first tried compiling a test program, I got a CC-E-NOSEMI error.  


$ ty test.c
#include <lib$routines>
#include <iledef>

main ()
{
unsigned int eventFlag;
ILE3 item_list[5];
int status;

status = lib$get_ef( &eventFlag );
return status;
}
$ cc test

ILE3 item_list[5];
.....^
%CC-E-NOSEMI, Missing ";".
at line number 7 in file SYS$SYSDEVICE:[ABIS.DELETE]TEST.C;12

int status;
^
%CC-E-BADSTMT, Invalid statement.
at line number 8 in file SYS$SYSDEVICE:[ABIS.DELETE]TEST.C;12

status = lib$get_ef( &eventFlag );
^
%CC-E-UNDECLARED, In this statement, "status" is not declared.
at line number 10 in file SYS$SYSDEVICE:[ABIS.DELETE]TEST.C;12


When I asked around, somebody told me I need to define __NEW_STARLET to get
the item list definintions to work.  He didn't know why.  So I tried it:

$ cc/defin=__NEW_STARLET test

        int coefficient [4] [],
............^
%CC-E-BADBOUNDS, In the declaration of "coefficient", the array bounds are incor
rectly specified.
at line number 2811 in module LIB$ROUTINES of text library SYS$COMMON:[SYSLIB]SY
S$STARLET_C.TLB;1

Using __NEW_STARLET seems to have broken lib$routines, so I hacked up my
program to define __NEW_STARLET after the inclusion of lib$routines and all
compiled fine:

$ ty test.c
#include <lib$routines>
#define __NEW_STARLET
#include <iledef>

main ()
{
unsigned int eventFlag;
ILE3 item_list[5];
int status;

status = lib$get_ef( &eventFlag );
return status;
}
$ cc test.c
$ 

Can anybody explain what is going on here?  Is there a way to avoid this
ugliness?  I'm using DEC C V5.5-003 on VMS V7.1

Thanks
Eric

  Actually, this is not a __NEW_STARLET question.

  Defining __NEW_STARLET results in fetching the following function prototype
  from lib$routines.h :

unsigned int lib$polyh(
	int *polynomial_argument [4],
	short int *degree,
	int coefficient [4] [],
	int *floating_point_result [4]);

  I'm not sure whether "coefficient [4] []," can be specified in a function
  prototype or not.

  I failed to understand from ANSI C why the compiler must give different
  results for the two following programs specifying incomplete array type
  in the function prototype:

int x(int y[]);

  compiles cleanly with DEC C V5.0-003 and higher.

int x(int y[1][]);

  causes "%CC-E-BADBOUNDS, ...the array bounds are incorrectly specified"
  error.

  Anyway, if this is the bug in the header, it should be QARed/IPMTed against
  VMS as OpenVMS owns this header file.

  Boris

> int coefficient [4] []

This says that "coefficient" points to an array containing 4 elements,
each of which is an array with an unspecified number of elements.  Therefore
the compiler can't know how far apart the 4 elements are spaced, so it
can't compute the address of  coefficient[1][0].

It looks as if this is meant to describe an array of 16-byte objects,
in a rather clumsy way.  If so, it should have said

	int coefficient [] [4]

All the problems you're having are in header files defined by the VMS group,
not the C team (though perhaps the C team has more expertise).  You should
discuss the problems in VAXAXP::VMSNOTES, or report problems with a QAR to VMS.

    	I'm pretty sure this turned out to be an SDL bug in generating
    these array parameters which has been fixed. However, to be sure, I'd
    take Bill's suggestion to QAR it against VMS.

Reply to .6

  I understand, that for 'int coefficient [4] []' "the compiler can't know
  how far apart the 4 elements are spaced, so it can't compute the address of
  coefficient[1][0]".

  The point is that 'int coefficient [4] []' is specified in the function
  prototype and it is not clear for me why the compiler should consider the
  address calculation at this stage. The function prototype provides no
  information about how the elements of the array are accessed.

  The program below compiles cleanly on Unix in the default std0 mode and even
  works :-). It does not compile on OpenVMS.

  I tried to find in ANSI C something, that would say, that such kind of
  declaration is illegal, but failed.

  Of course, lib$routines.h header should be fixed.

  Boris

/usr/users/boris> uname -a
OSF1 hitime.iso.dec.com V4.0 564 alpha
/usr/users/boris> cat x.c
#include <stdio.h>

void x(char y[4][])
{
  char *p = (char *)y;

  while ( *p )
    putchar(*p++);
  putchar('\n');
}

main()
{
  char y[5][2] = { {'a','b'}, {'c','d'}, {'e','f'}, {'g','h'} };

  x(y);
}
/usr/users/boris> cc -std0 x.c
/usr/users/boris> a.out
abcdefgh
/usr/users/boris>

Re: .8

>  I tried to find in ANSI C something, that would say, that such kind of
>  declaration is illegal, but failed.

Section 3.1.2.5, Page 24, lines  23-24 (also Footnote 17) disallow array types
from having an incomplete element type:

	"An array type describes a contiguously allocated nonempty set of
	objects with a particular member object type, called the element
	type.(17)"

	"(17) Since object types do not include incomplete types, an array
	of incomplete type cannot be constructed."

Section 3.5.4.2, Page 68, lines 9-10 state that if an array declarator
does not include a size within the [], the array type is an incomplete type.

Thus, char y[4][] is invalid by the above rule.

Your example program is interesting because "y" is a parameter, and parameters
whose type is "array of T" are rewritten by the compiler to have type
"pointer to T".

Defect Report 41 against the C Standard asked if declarations of the
form:

	void x(char y[4][]);

are OK because the compiler rewrites the invalid array parameter into
a pointer:

	void x(char (*y)[]);

and a pointer to an incomplete type is valid.

The committee's response was that such declarations are still invalid
because the original array declaration of the parameter stated out invalid.

The committee did point out that the standard did not require a diagnostic
for array of incomplete type, and so it could be extended.

DEC C did extend this for array declarations of the form:

	struct S;
	void x(struct S y[4]);

where the element type is an incomplete struct or union type (that construct
seems somewhat popular).

DEC C didn't extend this for when the element type is an incomplete array
type.   Since that case usually comes up when the programmer is confused
whether the first [] or last [] in a multidimensional array can be empty,
it seems wise to continue to complain about it.

Since the case in question (the VMS header) seems to be an example of
that confusion rather than a desire to use an extension, it seems to
validate this position.

As other notes have suggested, you should QAR the bad declaration in
the VMS header file against VMS.

> 	void x(char (*y)[]);
> 
> and a pointer to an incomplete type is valid.


Randy, what does y+1 mean in this context?  Or is that a circumstance that
"requires the size of the object"?

>As other notes have suggested, you should QAR the bad declaration in
>the VMS header file against VMS.

It's been done.  Thanks for the help.  I'm sure the future fixer of this bug
will find this discussion interesting.

    Oh, another user of __NEW_STARLET using lib$routines :-)
    This has been QARed in the V7.0 time frame, and as far as I know will be
    fixed if the latest SDL is used in building VMS.
    
    Hartmut

Re: .10

>Randy, what does y+1 mean in this context?  Or is that a circumstance that
>"requires the size of the object"?

You got the right answer.  A pointer to an incomplete type can be used in
any way that doesn't require the type to be complete.  So, you could assign
a pointer to an incomplete type to another pointer, pass it as an argument,
compare its value to another pointer or NULL, and so on.

You can't dereference such a pointer to see what it points at, or do
pointer arithmetic with the pointer.

"void" is defined to be an incomplete type.  "void *" is a pointer to
an incomplete type.  Therefore, most people have a lot of experience
using pointers to incomplete types without knowing it.

Only void * has the special property that it is compatible with any
other pointer type.  If you have source that looks like:

	struct S;	/* S is currently an incomplete type */
	struct T;	/* T is currently an incomplete type */
	struct S *sptr;
    	struct T *tptr;

	sptr = tptr;

the assignment will get an error.  Even though both sptr and tptr point
to incomplete types, they point to different incomplete types.