JOE@FHCRCVAX.BITNET (Joe Meadows) (07/21/88)
Okay, I've had my SDL routines sitting around for a while, & I've
given them out to lots of people. Since VMS 5.0 came in the door I've
had a chance to test SDL. I can see why the BASIC and Fortran installations
don't necessarily work. They've made some slight changes (they added a few
datatypes, and extended the structure slightly). So, in keeping with these
changes I modified my CC module. Basically the only changes I needed to
implement were adding the new "COMPLEX" data types (only found in
MTH$ROUTINES module). For the record, I punted with these data types and
simply output FFLOAT_COMPLEX, (and D, G, H versions), but I did not make
a #define for these data types. I plan on updating my DUMP module and
the documentation to reflect these changes, but I haven't yet.
Has anyone made much use of this utility? I was considering
posting it, but I thought I'd make this inquiry first. Has anyone
made any improvements to it (i.e. better handling of floating point
data types, or converted it to create some other language) ?
All the source and documents come to about 150 blocks. I
hate posting things in peices, because inevitably parts end up missing
and it turns into a big headache. So, if I do post it, is anyone
against my posting it as a whole?
For those of you completely in the dark, I'll explain.
My SDL routines take files (that DEC supplies with VMS) that
describe all the data structures that are found in the STARLET macro
library (or Bliss require files), plus a few, and can create C header
files. For instance, the as yet undocumented MAIL routines have an
associated definition file $MAILDEF, that describes the constants used
to call the mail routines. You could be the first on your block to have
these structures turned into C header files.
As I've pointed out in the past, these routines are of somewhat
limited value, since DEC doesn't include the LIB definitions. However,
for what is there, it works well. It also can create function prototypes,
which can save you a lot of headaches, all of the system services are
included, plus most of the run time library routines (LIB, OTS, MTH, STR,
SMG, NCS, PPL, etc..)
Now for a quick C language gripe about function prototypes.
Given the following section of code, (created by my SDL routines):
/* LIB$CREATE_DIR *
/
/* *
/
/* Create a Directory *
/
/* *
/
/* The Create a Directory routine creates a directory or subdirectory. *
/
/* *
/
unsigned long int lib$create_dir(
const struct dsc$descriptor *device_directory_spec,
...
/* const unsigned long int *owner_uic, */
/* const unsigned short int *protection_enable, */
/* const unsigned short int *protection_value, */
/* const unsigned short int *maximum_versions, */
/* const unsigned short int *relative_volume_number */
) ;
It sure would be nice if there were a way I could specify those trailing
arguments such that when compiling their datatypes would be checked too.
Hmm, worse yet, after looking through K & R (2nd edition), it looks like
everything past the ellipses "suffer default argument promotion" to
integer or double float. Bleah.. pooey. yuk. it wouldn't harm them
to allow arguments past the ellipses to actually mean something
would it? Luckily most everything is passed by reference in the run time
libraries, so they won't get promoted. Maybe if I could leave out the
comments surrounding the trailing arguments? Is it too late to get some
input to the ANSI commitee?
Cheers,
Joe Meadows Jr.
VAX/VMS System Manager / guru (still) in training
Fred Hutchinson Cancer Research Center
1124 Columbia St.
Seattle Wa. 98104
bitnet - JOE@FHCRCVAX
arpa - JOE%FHCRCVAX.BITNET@OLY.ACS.WASHINGTON.EDU
voice - (206) 467-4970