HDTenEightyP/NetNews huggingface dataset:
From: bruce@ais.com (Bruce C. Wright)
Newsgroups: vmsnet.internals,vmsnet.misc,comp.lang.c
Subject: RE: C Language question
Date: 9 Oct 92 11:01:02 GMT
Organization: Applied Information Systems, Chapel Hill, NC

In article <8543225@MVB.SAIC.COM>, "Andy, Systems Manager" <UDAA055@ELM.CC.KCL.AC.UK> writes:
> Nigel Arnot writes:
> 
>>Question: in C, if one declares char a[I][J], is there anything in the
>>language standard that guarantees that &a[0][0] is the first of a set of
>>I*J contiguous chars, and that a[i+1][0] is guaranteed to be the same
>>storage location as a[i][J] ).
>>
> 
> I suppose that it is conceivable for a compiler to use a mechanism for
> indexing that allows the individual elements of an array to be scattered
> in virtual memory. Assuming this is not the case then I think the
> following explanation holds.
> 
> A single `dimensioned' array or vector, such as a[i], is contiguous in
> memory in any language. (Obviously, otherwise indexing couldn't work).

This isn't quite true.  Most languages don't have a construct for
non-connected storage, but it is by no means impossible.  PL/I for
example has a mechanism for dealing with non-connected (non-contiguous)
storage:

	non_connected:	procedure;
	declare array (100, 100) fixed binary;
	declare sub entry ((*) fixed binary);

		call sub (array (*, 1));
		end non_connected;

Since elements are stored in row-major order in PL/I (as in just
about every major language except Fortran), this fragment passes to
the `sub' procedure a `slice' of the `array' which is formed from the
first column of the array - or in other words, from every 101st element
of the `array' as it is stored in memory.  The usual implementation is
for the compiler to write a descriptor that describes the required `step'
size for the array, and to pass that descriptor to the sub-procedure
rather than the address of the array itself.  Because this is less
efficient than indexing items in connected storage (because of the
implied multiply that the optimizer can't reduce in strength since
it doesn't know the multiplier at compile-time, unlike connected
storage where it does know the element size and therefore the step
size between elements), most implementations will pass the address
of the array rather than the descriptor if the formal argument is
declared to be `connected' or to have an explicit array size (the
(*) in the declaration for `sub' says the array can have any size).

Anyway this is rather off the track.  C doesn't have a concept of
`connected' versus `unconnected' storage of array items, and has
the explicit definitions that the address of the array is equal to
the address of array[0] and that successive elements of the array
are stored in sequential addresses.  Since a multi-dimensional
array in C is just an array of arrays, this implies that the entire
object must be in connected storage.  I don't think that you could
build a conforming compiler that didn't treat arrays the way Nigel
describes.

If there is really a lot of interest in this topic maybe it should be
moved to comp.lang.c or possibly vmsnet.misc rather than remain in
vmsnet.internals, which is a VMS internals newsgroup ...

Bruce C. Wright
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.internals
Subject: Re:  C Language question
Date: 9 Oct 92 14:32:00 GMT
Organization: Mitech Corporation, Concord MA

In article <718580974.504412.MILLER@TGV.COM>, MILLER@TGV.COM writes:
> Remember:  a[i] really means *(a+i) using the rules for pointer addition.
> a[i] is a macro construct.
> So a[i][j] really works out to *((char *)&*(a+i) + j), I think.

Hey, the guy who said to ask this on comp.lang.c is only 50%
correct. This is FAQ item!

But anyway, not true in all cases. In other words, if you see this in a program:

   a[i][j]

you don't really know if it means reference a vector of vectors or not.

It all depends on how a was declared. If char a[][], or char **a, that
is one thing.

But, it may also have been declared char a[5][10]. In which case
the resulting memory operations are more like what you would expect from
FORTRAN. Not two memory references but one.

The is one of the funky things about the C programming language.

-gjc
From: Yaacov Fenster @ISO 882-3153  10-Oct-1992 1818
Newsgroups: vmsnet.internals
Subject: Re: Finding a users disk name
Date: Sat, 10 Oct 92 17:17:06 MET
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

> From: VBORMC::"MACRO32@WKUVX1.BITNET" "MAIL-11 Daemon"  9-OCT-1992 21:11:38.53
> To:   MACRO32@WKUVX1.BITNET
> CC:
> Subj: Re: Finding a users disk name
>
> > Hello, I'm helping a friend of mine write a program that kinda simulates
> > a unix-type operating system. What we are having trouble with is the
> > cd ~user  command. We don't know how to get the person's disk area name
> > from their username. We'd like to be able to do cd ~user and have the
> > program give us back disk$xxx:[user]. Is there an easy way to do this,
> > and a way to do it without having operator privileges. Oh, we are using
> > VMS version 5.5
>
> What we do here for nonpriv access to low-level SYSUAF info is use the
> LIST command from AUTHORIZE to gererate a file with basic info, and then
> place it in a world readable spot with appropriate access privs so that
> anyone can use it.  A simple SEARCH on this file will return not only

How about this idea:
Use SYS$GETUAI to get the (up to date !!) information from the sysuaf.
Install the program using SYSPRV privileges (for access to all users) or GRPPRV
(for access to group only).
The items you need are UAI$_DEFDEV & UAI$_DEFDIR.
This has the added advantage of not breaking even if the LIST command from
 AUTHORIZE changes
it's format. And imagine new information being added to the database which is
 output using the LIST command -
which means that IT WILL CHANGE.

        Yaacov
-------------------------------------------------
Yaacov Fenster                  +(972)-3-9307239
y.fenster@ieee.org
fenster@taveng.enet.dec.com     DTN 882-3153
All the opinions voiced are mine alone and do not reflect anyone else's
opinion. (Including Dec).
From: "Franz Schoenbauer, Computer Science, +43-1-58801-4131"
Newsgroups: vmsnet.internals
Subject: VAX and Alpha: differences in image size for same program
Date: Wed, 07 Oct 1992 17:23:44 EDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

I've recently worked on an alpha and written a programm in MACRO.
I had a
x:      .blkb   16*1024*1024
statement and whoa! my image file had over 32000 blocks !

On the vax if you had that .blkb statement, the image file was just a
couple of blocks and (i believe) the image activator would create those
pages when you ran the image. On alpha it seems to be the linker who
preallocates them. Can this behaviour be modified ?

I have no "real" access to the alpha system, i can only put up
benchmark programs and have them compiled, linked and executed,
so please forgive me if a simple $ help link or something similar
would have told me waht to do.

Thanks, Franz.


Franz Schoenbauer, Tech. Univ. Vienna,      schoenbauer@eimoni.tuwien.ac.at
Resselg. 3/188  A-1040, Vienna, Austria     +43(1)58801 ext. 4131
Xref: sparky vmsnet.internals:1401 comp.os.vms:16179
From: lionel@quark.enet.dec.com (Steve Lionel)
Newsgroups: vmsnet.internals,comp.os.vms
Subject: Re: VMS shareable images, what's wrong with them?
Keywords: LIB$FIS
Date: 7 Oct 92 16:01:41 GMT
Article-I.D.: e2big.1992Oct7.160141.11374
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH


In article <1at59bINNcc7@network.ucsd.edu>, gkn@ucsd.edu (Gerard K. Newman) 
writes:
|>In article <1992Oct6.201520.24059@e2big.mko.dec.com> lionel@quark.enet.dec.com (Steve Lionel) writes:
|>
|>>[...]  Dynamic linking has been
|>>available for some years on VAX/VMS through LIB$FIND_IMAGE_SYMBOL.
|>
|>One of my favorite toys.  Thanks, if you had anything to do with it.
|>

While it may seem to some readers of this newsgroup that I've had my fingers in
just about everything, this is one I can't claim.  But I agree that this is
a wonderful routine and it is widely used in our own products.

There have been some side-discussions about global section ident matching and
why this feature is "bad", with some other comments appearing to recommend
dynamic linking as the only way it should be done.  The VMS method is a
compromise in some ways; it makes you work a bit harder at building proper
transfer vectors and not moving universal data cells around, but it has the
advantage of faster image activation as one is not doing all that name lookup
every time the image is run.   The issue of GSMATCH idents can be helped
somewhat by building in "dummy" transfer entries which, when called, signal a
"not implemented" error.  If you pad a transfer vector with these dummy
entries, and then take them over when adding new entry points, you don't have
to change the GSMATCH ident until you run out of dummy entries.  As long as
the newly linked image doesn't call the new routines, it can run on older
systems which don't have the new entries.  This method is now used in a number
of the VMS RTL shareable images.  (Someone even cleverly figured out how to
code the dummy entries so that they work whether CALLed or JSBed.)

Shareable images were an unusual idea in 1977 when they showed up in VMS V1,
albeit in a form that would seem harshly restrictive today.  But the
technology evolved into something that is astonishingly flexible and efficient.
We've also learned how to use them better along the way (the dummy entries
trick, for instance.)

--

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
From: HSIEH34@SNYBUFVA.BITNET
Newsgroups: vmsnet.internals
Subject: Re: Finding a users disk name
Date: 11 Oct 92 06:54:02 GMT
Organization: from SUNY College at Buffalo, NY 14222
X-Gateway-Source-Info: Mailing List

From:   BITNET%"MACRO32@WKUVX1.BITNET"  8-OCT-1992 16:43:24.01
To:     BITNET%"MACRO32@WKUVX1.BITNET"  "MACRO32"
CC:
Subj:   RE: Finding a users disk name

Return-path: <ARNE@ko.hhs.dk>
Received: from Jnet-DAEMON by SNYBUFVA.BITNET (PMDF #3312 ) id
 <01GPP4PVZUU8A733HB@SNYBUFVA.BITNET>; Thu, 8 Oct 1992 16:43:09 EDT
Received: From WKUVX1(MXMAILER) by SNYBUFVA with Jnet id 2590 for
 HSIEH34@SNYBUFVA; Thu,  8 Oct 1992 16:43 EDT
Received: from CUNYVM.BITNET (MAILER) by WKUVX1 (MX V3.1C) with BSMTP; Thu,
 08 Oct 1992 14:31:41 CDT
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 7874; Thu,
 08 Oct 92 15:01:23 EDT
Received: from KOPC by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with TCP; Thu,
 08 Oct 92 14:59:59 EDT
Received: from DECNET-MAIL (ARNE@KO) by kopc.hhs.dk (PMDF #3400 ) id
 <01GPPV0G0KQO8WW0A8@kopc.hhs.dk>; Thu, 8 Oct 1992 20:00:41 +0100
Date: 08 Oct 1992 20:00:41 +0100
From: Arne Vajhxj <ARNE@ko.hhs.dk>
Subject: RE: Finding a users disk name
To: MACRO32 <MACRO32@WKUVX1.BITNET>
Errors-to: MacroMan@WKUVX1.BITNET
Reply-to: MACRO32@WKUVX1.BITNET
Message-id: <01GPPV0G0KQQ8WW0A8@kopc.hhs.dk>
X-VMS-To: KOPC::IN%"@cunyvm.cuny.edu:MACRO32@WKUVX1.BITNET"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-transfer-encoding: 8BIT
X-ListName: "VMS Internals, MACRO, and BLISS Discussions"
 <MACRO32@WKUVX1.BITNET>

> Hello, I'm helping a friend of mine write a program that kinda simulates
> a unix-type operating system. What we are having trouble with is the
> cd ~user  command. We don't know how to get the person's disk area name
> from their username. We'd like to be able to do cd ~user and have the
> program give us back disk$xxx:[user]. Is there an easy way to do this,
> and a way to do it without having operator privileges. Oh, we are using
> VMS version 5.5

You can retrieve this information from SYSUAF with $GETUAI, if you have
privilige to (SYSPRV needed to do it for any user).

> Please e-mail replies,

And where do you think we should send this e-mail, when you do not supply
an e-mail address ?

PS: I am not sure this is the rigth forum for that question (no MACRO or
    internals stuff involved), but maybe I am just a little tired rigth now.

                                                          Arne

Arne Vajhxj                             local DECNET:  KO::ARNE
Computer Department                     PSI:           PSI%23831001304030::ARNE
Business School of Southern Denmark     Internet:      ARNE@KO.HHS.DK
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.internals
Subject: Re: Shared images, some differences on ALPHA
Date: 9 Oct 92 14:37:13 GMT
Organization: Mitech Corporation, Concord MA

In article <1992Oct8.151434.719@cmkrnl.com>, jeh@cmkrnl.com writes:
> That's odd -- I could'a sworn that globalREF's would become extern's.   To
> actually define the space (equivalent of globaldef), you use an unadorned
> declaration (no 'extern') outside all procedure bodies.  That's how I was told
> to do it by one of the DEC Alpha folks in Atlanta... 

It could be that the VMS ALPHA compilers have some VAX-C compatibility in them,
such that (sort of)

#define globaldef
#define globalref extern

but it could be that whoever was hacking OSF-MOTIF decided to RUB IT IN
that there was something funny about VMS on the VAX, or perhaps an early
version of the VMS ALPHA C compiler didn't have those two trivial items.

-gjc
From: 737ochs@gw.wmich.edu
Newsgroups: vmsnet.internals
Subject: Re: Finding a users disk name
Date: 7 Oct 92 18:45:25 EST
Distribution: world,local
Organization: Western Michigan University

In article <1992Oct7.122253.1068@galaxy.gov.bc.ca>, ewilts@galaxy.gov.bc.ca (Ed Wilts) writes:
> In article <7OCT199210243904@carat.arizona.edu>, jms@carat.arizona.edu (A virtually vegetal non-entity) writes:
>> In article <1992Oct7.031040.5662@gw.wmich.edu>, 737ochs@gw.wmich.edu writes...
>>>We don't know how to get the person's disk area name
>>>from their username. We'd like to be able to do cd ~user and have the 
>>>program give us back disk$xxx:[user]. 
>> 
>> Do a $TRNLOG on SYS$LOGIN.  If you just want the device, look at
>> SYS$LOGIN_DEVICE.
> 
> In Unix, cd ~user sets your default directory to that of *another* user. 
> Translating SYS$LOGIN_DEVICE only makes sense if you're looking for your own
> device.

Thank you...Almost all of the replies I had told me the same thing...to use
sys$login and sys$login_device, which is only gonna work for my area, (if I'm
using the program)
I guess it's not possible without sys privs, everyone else who didn't tell me
about sys$login has told me that it wasn't possible.

Thanks anyway...
Fred Ochs
From: SYSMGR@IPG.PH.KCL.AC.UK
Newsgroups: vmsnet.internals
Subject: C Language question
Date: Thu,  8 OCT 92 11:17:27 BST
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

(To those who get offended by questions that stray outside a group's main
intention - Sorry, please hit delete now. I'm not sure what the appropriate
mail list is, and I do know that the folks that follow this one are likely
to know!)

Question: in C, if one declares char a[I][J], is there anything in the
language standard that guarantees that &a[0][0] is the first of a set of
I*J contiguous chars, and that a[i+1][0] is guaranteed to be the same
storage location as a[i][J] ).

A friend asserts that it is, and says his experience on several systems
'proves' this. My belief is that there is nothing that says this will
always be the case, and that the only constraint is that every valid pointer
a[i] will point to J chars. Which of us is right?

        Yours,
                Nigel Arnot

                NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk   (internet)
                NRA%uk.ac.kcl.ph.ipg@ukacrl.bitnet        (bitnet)

Xref: sparky vmsnet.internals:1411 comp.os.vms:16192
Newsgroups: vmsnet.internals,comp.os.vms
Subject: Re: VMS shareable images, what's wrong with them?
From: jms@carat.arizona.edu (A virtually vegetal non-entity)
Date: 7 Oct 1992 10:49 MST  
Reply-To: jms@Arizona.EDU
Distribution: world,local
Organization: University of Arizona MIS Department - Mosaic Group
X-Lunar-Date: 1 day, 17 hours, 48 minutes since the first quarter of the moon
News-Software: VAX/VMS VNEWS 1.50A   

Warning: If you don't understand the concept of "subtle joke," don't
read this. 

In article <ld5vdbINN763@news.bbn.com>, mjensen@BBN.COM (Martin Jensen) writes...
> 
>    If  you  don't  have  anything  else  to  offer,  I,  for  one, would
>    appreciate it if you would go find another thread to flame.
> 

This, for all of you who haven't been hanging out on alt.flame, is what's
known as the "self righteous" flame.  Some people think of this as a
contribution to the discussion, but, in fact, it's just as much of a flame
as Ehud's (or even Carl's) writings.  Because the poster has chosen timely,
genteel words, you may have been fooled into believing that Mr. Jensen
was not flaming.

Wrong.

Coming out in a public forum and dressing someone down for their real or
imagined behavior in a way which is out of the charter of the newsgroup is
just as serious a crime, no matter how you write it.  In fact, one might
argue that Mr. Jensen is guilty of even worse a crime than Mssrs. Gavron
and Lydick, since his posting contained no technical information at all,
while those he accuses of malfeasance at least brought out data of some
sort (even if hidden in invective which Mr. Jensen's mind cannot sort
from content).  

If Mr. Jensen wasn't a brain dead slime breath pond scum hypocrite, he
would have sent the message directly to Carl and Ehud, and saved the
rest of us his mindless mumblings.  Damn this pisses me off!  IT REMINDS ME
OF THOSE GODDAM POLITICALLY CORRECT IDJITS WHO ACT AS THOUGHT POLICE GRRRR
SNORT PAW PAW ARRRGGGGGHHHHHHHHHHHHHHHHHHHH WHERE THE HELL'S MY LITHIUM?

jms

Joel M Snyder, 1103 E Spring Street, Tucson, AZ, 85719 
Phone: 602.882.4094 (voice) .4095 (FAX) .4093 (data)
BITNET: jms@Arizona  Internet: jms@arizona.edu  SPAN: 47541::telcom::jms
Yow!  It's a hole all the way to downtown Burbank!
From: Hunter Goatley <goathunter@WKUVX1.BITNET>
Newsgroups: vmsnet.internals
Subject: Stupid .es mailers....
Date: Thu, 15 Oct 1992 14:43:29 EDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

I've removed the .es addresses from the MACRO32 and Info-Zip lists.
They're the ones responsible for the stupid posts back to the lists of
the bounced mail.  I *hate* it when sites have broken mailers....

My apologies in advance for any more that make their way through....

Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goathunter@WKUVX1.BITNET, 502-745-5251
From: Ehud Gavron 602-570-2546 <GAVRON@IT.SUNQUEST.COM>
Newsgroups: vmsnet.internals
Subject: ...never mind...
Date: Tue, 13 Oct 1992 17:23:13 -0700 (MST)
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

I was passing the address of a pointer instead of a value :-)

Ehud
From: REGI's <NUNEZ@esevvx.cica.es>
Newsgroups: vmsnet.internals
Subject: (None)
Date: Thu, 15 Oct 1992 15:33:00 UTC+0100
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

>X-Envelope-to: MACRO32@WKUVX1.bitnet
>X-VMS-To: IN::"MACRO32@WKUVX1.BITNET"

1
14-OCT-1992 00:48:19.27
   1 00:00:00.00
15-OCT-1992 00:48:19.27
@UKCC.uky.edu:MacroMan@WKUVX1.BITNET
gutier@SEVAXU.CICA.ES

Received: from UKCC.uky.edu by ESEVVX.CICA.ES ; 11-OCT-1992 00:48:17.24
Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 9437; Sat, 10 Oct 92 19:47:08 EDT
Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 2554;
 Sat, 10 Oct 92 19:47:07 EDT
Errors-To: MacroMan@WKUVX1.BITNET
X-ListName: "VMS Internals, MACRO, and BLISS Discussions"
    <MACRO32@WKUVX1.BITNET>
Received: from CUNYVM.BITNET (MAILER) by WKUVX1 (MX V3.1C) with BSMTP; Sat, 10
          Oct 1992 18:09:35 CDT
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 3959; Sat,
          10 Oct 92 16:27:58 EDT
Received: from MVB.SAIC.COM by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with TCP;
          Sat, 10 Oct 92 16:27:56 EDT
Relay-Version: VMS News - V6.0-3 14/03/90 VAX/VMS V5.5; site arizona.edu
    darwin.sura.net!haven.umd.edu!uunet!decwrl!pa.dec.com!nntpd2.cxo.dec.com!ads
erv .enet.dec.com!winalski
X-Newsgroups: vmsnet.internals,comp.os.vms
Subject: Re: VMS shareable images, what's wrong with them?
From: <winalski@adserv.enet.dec.com>
Date: Sat, 10 Oct 1992 19:40:31 GMT
Reply-To: MACRO32@WKUVX1.BITNET
            <ld5vdbINN763@news.bbn.com> <6372@npri6.npri.com>
Organization: Digital Equipment Corporation, Nashua NH
To: MACRO32@WKUVX1.BITNET
X-Gateway-Source-Info: USENET


In article <6372@npri6.npri.com>,
murphy@npri6.npri.com (David P. Murphy) writes:
|>
|>it's not even a religious issue --- there's nothing to discuss.
|>dec decided to implement shareable images in a certain way, and so they did,
|>and that's all there is to it.  i certainly wish they had done it differently,
|>but there's no chance of changing it now because it would be incompatible.

Not true.  The image header record has major and minor version IDs precisely
so that the image format can be changed in an upward-compatible fashion.  As
long as the Linker and image activator continued to recognize and process
old-format images correctly, in principle anything goes as far as the changes
that could be made in the new format.

--PSW
From: jeh@cmkrnl.com
Newsgroups: vmsnet.internals
Subject: Re: Shared images, some differences on ALPHA
Date: 8 Oct 92 15:14:34 PDT
Organization: Kernel Mode Consulting, San Diego, CA

In article <3026@mitech.com>, gjc@mitech.com (George J. Carrette) writes:
> By the way, LINK/SHARE works a bit differently on ALPHA. Indications I've
> gotten (e.g. months ago from OSF/MOTIF source codes) are that there is
> no longer any "globalref" or "globaldef" stuff, for example. e.g.
> 
>      #if defined(VMS) && !define(ALPHA)
>      globaldef ...
>      #else
>      extern ...
>      #endif
> 
> was seen.

That's odd -- I could'a sworn that globalREF's would become extern's.   To
actually define the space (equivalent of globaldef), you use an unadorned
declaration (no 'extern') outside all procedure bodies.  That's how I was told
to do it by one of the DEC Alpha folks in Atlanta... 

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.internals
Subject: Re: Shared images, some differences on ALPHA
Date: 9 Oct 92 14:21:07 GMT
Organization: Mitech Corporation, Concord MA

In article <1992Oct9.054726.1@cc.curtin.edu.au>, zrepachol@cc.curtin.edu.au (Paul Repacholi) writes:
> In article <3026@mitech.com>, gjc@mitech.com (George J. Carrette) writes:
>>      #if defined(VMS) && !define(ALPHA)
> Would this perchance be a VAX-C/DEC-C difference, rather than LINK?

False. Globaldef is something that the C compiler is telling the linker.
It is the linker that is responsible for wanting that kind of info in
the first place.

If DEC-C was running on VAX/VMS it would need to have something
like GLOBALDEF to talk to the LINK command properly.