Conference turris::vaxc

5610.0. "Customer Concerns VAX C to DEC C" by NWD002::DENIGAN_KE (Keith Denigan) Wed May 28 1997 16:49

    Hello,
    
    Below is a mail message from one of our customers expressing some
    concerns on VAX C - DEC C. Any insight/advice will be greatly
    appreciated.
    
    Thanks in Advance,
    
    Keith
    
    
From:	NWD002::US3RMC::"[email protected]" "Warren Lewis" 28-MAY-1997 12:21:10.30
To:	nwd002::denigan_ke
CC:	
Subj:	DECC vs VAXC

Hi, Keith,
Here is a description of our problem.
We have used VAX C for a long time- 8 or 10 years. We have a central
development system from which we deploy executables to the target
machines. We have a large number of shared object libraries against
which many projects link.

My understanding is that a program with DEC C code in it cannot have
any VAXC code in it and vice versa, the reason being that the runtime
libraries have duplicate entry points. 

This implies that we need to make a knife-switch cutover. From the time
we start to compile ANYTHING in DEC C it won't work until all the shared
stuff it links against is migrated. But as soon as ANY shared stuff if
migrated the old VAX C stuff will no longer work.

The implications range between entailing a number of hours too large to
estimate, to sheer catastrophe. As a result we have never taken the
first (read: ONLY) step. Now we are seeing layered products which require
DEC C and we are in a bind.

Does DEC have any migration plans? The only option I can think of is to
replicate our environment completely, and have a long period of mass
confusion while we try and run out of both areas and get the migration
done. Remember that this is in a factory and can affect product quality
and market position. It doesn't seem like DEC to let us hit the wall in
a ball of flame like this. Is there some way to migrate incrementally?

	thanks,
		Warren

% ====== Internet headers and postmarks ======
% Received: from mail1.digital.com by us3rmc.pa.dec.com (5.65/rmc-22feb94) id AA09630; Wed, 28 May 97 12:06:15 -0700
% Received: from on-ramp.ior.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA27216; Wed, 28 May 1997 11:59:14 -0700
% Received: from trentwood by on-ramp.ior.com via rmail with uucp id <[email protected]> for nwd002.enet.dec.com!denigan_ke; Wed, 28 May 97 11:34:30 -0700 (PDT) (/\##/\ Smail3.1.30.16 #30.4 built 17-mar-96)
% Received: by email.kaisertwd.com (DECUS UUCP ///1.3-1/2.5/); Wed, 28 May 97 11:11:49 PDT
% Date: Wed, 28 May 97 11:11:49 PDT
% Message-Id: <[email protected]>
% From: "Warren Lewis" <[email protected]>
% Subject: DECC vs VAXC
% To: nwd002::denigan_ke
% X-Vms-Mail-To: @DIST:DENIGANKE
% X-Vms-Mail-Cc: LEWIS

    I strongly encourage you to look at the Migration Guide which can be
    located at:
    
       DECC::DECC$KIT:[VAX]DEC_C_MG.PS
    
    Extensive work was done to ease this migration.  The statement that VAX
    C and DEC C cannot coexist in an image is incorrect and is explained in
    much more detail in this Migration Guide.  When the user calls function
    strlen in VAX C, a reference is made to a symbol named strlen.  When
    compiled with DEC C, the reference is to decc$strlen.
    
    Duane

   Incremental migration -- images containing a mixture of both VAX C
   and DEC C code, as well as other languages -- is fully supported.

   As for a cut-over, I have hauled over various large piles of VAX C
   code to DEC C over the years, and the compiler found various latent
   bugs in the process...

   And with the CC/DECC/STANDARD=VAXC qualifier, nearly all of the older
   (and non-ANSI) VAX C behaviour is supported under DEC C -- in other
   words, the cut-over might be as "complex" as a couple of full-pass
   recompilations of the source modules.  (I would expect to need more
   than one pass, give DEC C will likely uncover some number of latent
   bugs in your customer's code, bugs that will need to be resolved...)

   As was mentioned, the migration guide is definitely worth reading.

   Also remember to include the CC/DECC/PREFIX=ALL qualifier -- the lack
   of the /PREFIX qualifier is a common error among new DEC C users...

        To just recompile the VAX C code with the DEC C compiler
        without first changing any of it, you might try
        
        	$ cc/decc/standard=vaxc -
        		/extern_model=common_block/share_globals -
        		/assume=writable_string_literals -
        		/prefix=all
        
        That collection of command line qualifiers (did I miss any?)
        will go a long way towards using the VAX C code as is with
        the DEC C compiler.
        
        If you want to modify the source code, to port it from VAX C
        to ANSI C, you can start even before you install the DEC C
        compiler.  The VAX C compiler's /STANDARD=PORTABLE qualifier
        can be used (perhaps with /NOOBJECT as you may just want the
        diagnostics) to show you some of the diagnostics messages you
        will get by compiling the VAX C code with the DEC C compiler
        without its /STANDARD=VAXC mode.  Fixing the VAX C code to
        not produce those diagnostic messages under /STANDARD=PORTABLE
        will start the port to ANSI C.
        
        Dan