Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!rutgers!ucla-cs!zen!ucbvax!VENUS.YCC.YALE.EDU!LEICHTER
From: LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU)
Newsgroups: comp.os.vms
Subject: re: VAX C 2.2, VMS 4.6, VAXCRTL.EXE, and malloc()
Message-ID: <8712280131.AA22924@ucbvax.Berkeley.EDU>
Date: 27 Dec 87 21:15:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 48


	We recently upgraded our OS to VMS 4.6, but left our c compiler at
	2.2.  Programs linked under 4.4 exhibit the following behaviour from
	malloc().

This combination IS supported, last I heard.  Note that you will be able to
use the new library functions, though you won't have the new include files
that describe them.  (BTW, the VAX C V2.3 COMPILER is supported on VMS V4.4,
too.  In fact, it's supported all the way back to V4.2.)

	If there is no more memory available (not so strange on a microvax
	with a small disk), 

Eh?  What does "no more memory" have to do with having a small disk?

			    the routine signals %SYSTEM-F-RADRMOD, reserved
	addressing fault.  If I relink using the V4.6 linkable library
	(VAXCRTL.OLB), malloc returns NULL as advertised.

	Is VMS no longer upward compatible?

Oh, come on.  Producing a RADRMOD signal rather than the documented NULL
return is clearly a bug somewhere.  Do you want new versions to retain old
bugs?  :-)

					     Is this related to our old
	compiler with the new operating system?  Shouldn't I be able to run (&
	sell) programs linked on the previous (or 2nd previous) version of
	operating system and compiler?

I don't know for certain, but I'd guess that something changed in the REST of
VMS that triggered a latent problem in the older VAX C RTL.  In particular,
malloc() and friends ultimately call LIB$GET_VM and friends; any changes to
those could have done this.

	Or is this a bug in VAX C 2.2?

Since you apparently didn't see a problem when you combined the old C library
with the old VMS RTL, it's some sort of bug in the interaction between the
old library and the new VMS.  Since the new C library fixes the problem, I
doubt you are likely to be able to interest anyone in tracking this down in
detail.

A suggested workaround:  Don't use VAXCRTL.OLB; link against the shareable
image (VAXCRTL.EXE).  You can keep a version of the VMS V4.4 VAXCRTL.EXE
around and link against THAT; then the resulting image will run fine on V4.4
systems, using the V4.4 shareable image; and it will also run fine on V4.6
systems, using the V4.6 shareable image.
							-- Jerry