[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::decc

Title:DECC
Notice:General DEC C discussions
Moderator:TLE::D_SMITHNTE
Created:Fri Nov 13 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2212
Total number of notes:11045

2120.0. "VAX vs. _VMS Macro Usage" by LOCH::SOJDA () Wed Mar 12 1997 14:10

    I received the following from a customer today.  Can anyone provide an
    answer to this?
    
    Thanks in advance,
    
    Larry Sojda
    
    ***********************************************************
    
    We understand that DEC is recommending that people use the __VMS macro
    instead of the VAX macro on the Alpha machines.  We are having a hard
    time convincing people in our division about doing this.  If I get
    an answer to the following questions, we might be able to come to
    closure on this issue:
    
    1. Why is DEC recommending that the VAX macro be replaced by __VMS?
    
    2. Would there be any harm if we decide to continue using the VAX macro
    on the Alpha by defining the macro ourselves (CC/DEFINE=VAX)?  In other
    words, do you see a conflict with DEC if we define the VAX macro on the
    Alpha?
T.RTitleUserPersonal
Name		DateLines
2120.1VAX is not a synonym for VMSXDELTA::HOFFMANSteve, OpenVMS EngineeringWed Mar 12 1997 15:3927
   1: Because VAX and VMS are not (no longer) synonymous.

	VAX is a hardware platform that runs various operating
	systems including VMS, and VMS is an operating system
	that runs on various platforms including VAX.

	DEC C, for instance, can specifically compile C code
	on various pairs of platforms (VAX, ALPHA) and operating
	systems (VMS, UNIX).

	VAX and ALPHA are how one can conditionalize features
	of aspecific hardware platforms, while VMS is how one
	can conditionalize features specific to the OpenVMS
	operating system from those of other operating systems.

   2: It is quite possible that a local re-definition of a compiler
	definition may cause some unspecified `untoward' behaviour
	in the header files, either now or some time in the future.

	If local preprocessor definitions are required, they should
	use local names, and should seriously consider using facility
	prefixes on these names to prevent name collisions.

   A PERL script can "repair" C code that misuses these definitions
   quite easily.