STEINBERGER@KL.SRI.COM (Richard Steinberger) (09/10/87)
On pages 6-10 to 6-12 of the VAX-C RTL Ref. Man. (March 1987) are described the "memchr" and "memset" functions (and some others). I tried to use these in a short C program. The program compiled OK, but the linker couldn't resolve these references. I looked in Appendix B of the same manual: On page B-12 and B-13 it states that these functions (entry points actually) are found in C$MEMFUNC. When I do a LIB/LIST of VAXCRTL.OLB, C$MEMFUNC isn't there although many other C$xxxxxx modules are present. Has anyone else experienced this problem? Can anyone verify that C$MEMFUNC exists as a module (where?)? Thanks to all who reply. Ric Steinberger steinberger@kl.sri.com P.S. I'm using version 2.3 of VAX-C. -------
nagy%warner.hepnet@LBL.ARPA (09/10/87)
>On pages 6-10 to 6-12 of the VAX-C RTL Ref. Man. (March 1987) are described >the "memchr" and "memset" functions (and some others). I tried to use >these in a short C program. The program compiled OK, but the linker >couldn't resolve these references. > P.S. I'm using version 2.3 of VAX-C. And, I'll bet, VMS V4.4 or V4.5... The problem is that the VAXCRTL.EXE image is now shipped with VMS - just like all the other RTL images for languages (FORRTL, BASRTL, etc.) and non-language support (SMGRTL, etc...). If you look at the title page of the VAX C Run-Time Library Reference Manual, under "Operating System and Version", you will see that VMS V4.6 or higher is required. THIS IS ONLY FOR THE "new" RTL routines. The compiler and the .H files work just fine under VMS V4.4 and V4.5 - just stay away from the "new" RTL functions. P.S. VMS V4.6 is expected to begin shipping to us customers next week. = Frank J. Nagy "VAX Guru" = Fermilab Research Division EED/Controls = HEPNET: WARNER::NAGY (43198::NAGY) or FNAL::NAGY (43009::NAGY) = BitNet: NAGY@FNAL = USnail: Fermilab POB 500 MS/220 Batavia, IL 60510
leichter@VENUS.YCC.YALE.EDU ("Jerry Leichter") (09/10/87)
On pages 6-10 to 6-12 of the VAX-C RTL Ref. Man. (March 1987) are described the "memchr" and "memset" functions (and some others). I tried to use these in a short C program. The program compiled OK, but the linker couldn't resolve these references. I looked in Appendix B of the same manual: On page B-12 and B-13 it states that these functions (entry points actually) are found in C$MEMFUNC. When I do a LIB/LIST of VAXCRTL.OLB, C$MEMFUNC isn't there although many other C$xxxxxx modules are present. This (and related) questions are probably making the release timing skew between VAX C V2.3 and VMS V4.6 the greatest source of VMS headaches in history. The problem is this: The VAX C product consists of a compiler and a run-time library. You get the compiler when you order VAX C; you get the run-time library, on the other hand, with VMS. They are separate products, and the RTL is NOT shipped with the (compiler) kit. This division is, with V2.3, even reflected in the documentation: There are now separate documents for the compiler and the library, and if you look REALLY closely at the cover pages, you'll discover that the compiler documentation says that the product it describes supports VMS V4.2 or higher - but the RTL documentation says IT supports VMS Version 4.6 or higher. So...you'll have to wait until VMS V4.6 to use the memxxx functions; they are not in the V4.5 version of the VAX C library. To anticipate the obvious question - why do things this way? Past practice was to ship language RTL's with VMS, and also with the compiler kit when there were major changes. This has, in the past, led to headaches, like people installing the compiler on a more recent VMS system and replacing an even-newer RTL with the "new" one from the kit is one, though that could be fixed by a more clever installation procedure. A more severe problem, harder to deal with, is that of support: The RTL's are a part of the "base VMS system", and if new RTL's are shipped with compilers, different "sub-versions" of VMS start to exist: VMS V4.5 with the V2.2 RTL; VMS 4.5 with the V2.3 RTL; and so on. If someone on a VMS V4.5/V2.3 RTL system compiles and links a C program, then moves that program to a VMS V4.5/V2.2 RTL system, the program won't work - although it's "the same version" of the operating system. (This happened a while back with PASCAL.) [Yes, if the program were linked against the .OLB, and so carried its own copy of the library routines it needed, it MIGHT work - but suppose the new library routines depended on some VMS system service, or something from the rest of the VMS RTL, that was added in VMS V4.6? Then you'd have a program that MIGHT work, sometimes, depending.] Shipping the RTL ONLY with VMS eliminates the "sub-versions". However, it leads to the problem being discussed here: There are now what amount to "sub- versions" of the COMPILER. Most of the time, this doesn't happen or isn't visible to the user: Few language systems have as extensive and as visible an RTL as C - most of the things in, say, PASRTL are never called directly by the user, but are called as a result of compiler-generated expansions of language elements. If there are any changes to such code, the new compiler would simply not work correctly without the new version of VMS - and so wouldn't be supported on the earlier version of the OS. C, however, has a fairly de-coupled compiler and RTL, so it is quite possible to have a compiler that runs on V4.2 and works with any RTL from V4.2 to V4.6. Add to this delays in the shipment of VMS V4.6, and you have a headache. -- Jerry ------
face@amethyst.UUCP (Chris Janton) (09/10/87)
C version 2.3 requires version 4.6 of VMS. The compiler will run but new functions provided in 2.3 come with the latest release of VAXCRTL.EXE (the shared runtime library.) You won't be able to use the new functions until you install version 4.6.
john@auspyr.UUCP (John Weald) (09/11/87)
On the subject of the memxxx functions here is a bug. We are running
on one of those strange combinations mentioned in earlier articles.
We have VMS 4.5 with a C 2.3 compiler and RTL on a uVAX.
It would appear that memset() does not save/restore the registers. Here
is a sample program:
++++++++++++++++++Cut here+++++++++++++++++++++++++++++++++++++++
main(argc, argv)
int argc;
char *argv[];
{
char b[100];
int r1; /* These guys will be in registers */
int r2;
int r3; /* This guy is in R6 */
int r4;
int r5;
int r6;
/* assign them something that the compiler */
/* will not be clever with */
r1 = atoi(argv[1]);
r2 = atoi(argv[2]);
r3 = atoi(argv[3]);
r4 = atoi(argv[4]);
r5 = atoi(argv[5]);
r6 = atoi(argv[6]);
f(r1, r2, r3, r4, r5, r6);
memset(b, 0, sizeof(b));
f(r1, r2, r3, r4, r5, r6);
}
f(a1, a2, a3, a4, a5, a6)
int a1, a2, a3, a4, a5, a6;
{
printf("%d %d %d %d %d %d\n",
a1, a2, a3, a4, a5, a6);
}
Compile it in the usual manner. Install the command with the usual:
proggie = "$ dev:[path]proggie.exe"
and run it as:
proggie 1 2 3 4 5 6
the output is:
1 2 3 4 5 6
1 2 0 4 5 6
Using the debugger it is R6 that gets corrupted.
Cheers!
John Weald Austec Inc. San Jose
--
UUCP: {styx,imagen,dlb,gould,sci,altnet}!auspyr!johnleichter@VENUS.YCC.YALE.EDU ("Jerry Leichter") (09/12/87)
On the subject of the memxxx functions here is a bug. We are running on one of those strange combinations mentioned in earlier articles. We have VMS 4.5 with a C 2.3 compiler and RTL on a uVAX. It would appear that memset() does not save/restore the registers. Here is a sample program: [Example program elided; it shows R6 being trashed] The fact that you HAVE memset at all on a VMS V4.5 system means you got a V4.6 VAXCRTL from somewhere. My guess is that you were a field test site for VAX C and are still using the FT VAXCRTL. Guess what: A bug found (and fixed) during field test was that memset wasn't saving the right registers. -- Jerry PS: If you were NOT a FT site, you got your code "under the table". Don't look for sympathy in that case.... ------