On Jun 24, 2010, at 8:24 PM, John E. Malmberg wrote:
It may be the systems job to provide the correct headers, and it
does for the structures and the constants, but in my opinion it is
not doing the job correctly for the sys$* and lib$* routines.
Setting the __NEW_STARLET macro fixes some but not all the issues
for starlet.h, however code that needs to build on older versions of
VMS can not depend on that macro working.
Those definitions are limited to header files named starlet.h and *
$routines.h and with the home rolled definitions, there is no reason
to include them, as all they have is almost useless prototypes.
But the alternative to including them is to maintain our own prototype
for *every* routine we use, which means adding a new prototype every
time we use a routine we haven't used before.
If the home rolled ones are generating errors, then either they
should be fixed or the code calling them is not using the correct
types and should be fixed. When used properly they will catch
programming errors, and they can also help the compiler create more
optimal code, even when building on the oldest version of VMS that
perl can be built on.
I don't need to be sold on the benefits of good prototypes, but the
ones there now conflict with the system headers. Fixing them is a
maintenance burden. Adding more would increase that burden. When
they aren't perfect, they break the build on some compiler or OS
version that the developer who added the prototype couldn't or didn't
test. I could see trying to get __NEW_STARLET working, but
maintaining our own starlet.h is crazy.
The code that currently uses LIB$FIND_IMAGE_SYMBOL needs to be
updated
to do the following:
1. If the symbol is over 31 characters:
a. Try loading it in exact case but CRC shortened the way the
C compiler does.
b. Try loading it in upper case but CRC shortened the way the
C compiler does.
c. Try loading it in exact case but truncated to 31 characters.
d. Try loading it in upper case but truncated to 31 characters.
2. For symbols 31 characters or less, try looking for it in exact
case
first and then in all upper case.
We have complete control over how the symbols are created at build
time.
I can't see any good reason to add this level of complexity and
processing at run time.
It gives us more flexibility in what images that we can dynamically
load. It will also allow the eventual retirement of VMS specific
code in the XS generation instead of trying to keep it in sync when
there are changes, and it avoids issues like Mark is seeing.
While the routines are fairly general purpose, I think in practice the
only lib$find_image_symbol call that Perl does is to get the
boot_Extension__Name symbol when loading an extension. I believe
everything loaded after that is in the hands of the image activator,
so what we do at run time would have a limited impact. We can control
compile-time and link-time options and we can put aliases in the
linker option files, but I don't think jumping through a lot of hoops
to allow different rules for the boot_XXX symbol than we allow for
everything else is much of a win.
________________________________________
Craig A. Berry
mailto:craigbe...@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
