HDTenEightyP/NetNews huggingface dataset:
From: Chris Petroff <CHRIS@aardvark.ucs.uoknor.edu>
Newsgroups: vmsnet.internals
Subject: Re: Finding a users disk name
Date: Fri, 9 Oct 92 10:05 CDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

> 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
the home directory/device of a user, but also his UIC, Personal Name,
privs (NORMAL/ALL), base priority and Account name.  After we make the
SYSUAF.LIS file, we strip out some stuff and leave only the username,
owner/personal name, UIC, and Directory.  We have a command file which
does this for us which we run after adding/deleting accounts.  We also
have several utilities which are driven off this file...

This allows nonprivilaged access to the info, but the real benifit at
the time it was implimented (on a 11/780) was that we did not keep
trashing SUSUAF.DAT everytime we wanted to look someone up!  On a
6320 (what we have now) it's still more efficient but probably not so
big a deal....

This may seem like a bothersome way of doing it, but it is VERY simple
and easy to maintain.  Also, it is not likely to break with the next
version of VMS, but if it does, it is real simple to fix!

Just my $.02

:-)

Chris
From: REGI's <NUNEZ@esevvx.cica.es>
Newsgroups: vmsnet.internals
Subject: (None)
Date: Thu, 15 Oct 1992 16:54: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
12-OCT-1992 18:38:36.99
   1 00:00:00.00
13-OCT-1992 18:38:36.99
@UKCC.uky.edu:MacroMan@WKUVX1.BITNET
gutier@SEVAXU.CICA.ES

Received: from UKCC.uky.edu by ESEVVX.CICA.ES ;  9-OCT-1992 18:38:34.66
Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 4830; Fri, 09 Oct 92 13:29:31 EDT
Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 6169;
 Fri, 09 Oct 92 13:29:29 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; Fri, 09
          Oct 1992 12:21:37 CDT
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 7982; Fri,
          09 Oct 92 13:15:13 EDT
Received: from IT.SUNQUEST.COM by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with TCP;
          Fri, 09 Oct 92 13:15:05 EDT
Date: Fri, 9 Oct 1992 10:14:58 -0700 (MST)
From: Ehud Gavron 602-570-2546 <GAVRON@IT.SUNQUEST.COM>
Reply-To: MACRO32@WKUVX1.BITNET
To: macro32@WKUVX1.BITNET
Subject: DECUS Get-together for MACRO32:  Monday Night, 8:00PM, Hilton enterance

Date sent:  9-OCT-1992 10:09:02


        One month ago I asked if any of you wanted to do a get
        together at DECUS one night and go out to dinner.  The
        concensus of the responses is yes.

        People were asked to let me know a preferred time with
        a place if they knew of one.

        Selected day:   MONDAY!!!

        Selected time:  8:00PM

        Selected place: A restaurant (not fast food) to be chosen

        MEETING LOCATION: Right inside the front doors of the Las
                        Vegas Hilton at 8PM on Monday night.


        Thanks to all who responded!

        Ehud


Respondents and data included:
Dan Wing        DWING@UH01.Colorado.EDU
Day:            Sat,Mon,Tue,Thu,Fri
Place:          Any place with dark beer

Bruce Miller    miller@tgv.com

Mars Akerberg   mats@rigel.efd.lth.se

Don Roberts     Don@Beckman.Com
Day:            Best Monday, any evening ok
Place:          Not fast food

Gerald Lester   gwl@cpu.com
Day:            Sunday, Monday
Place:          Food should not be moving *too* fast

Ron Kaledas     RON@LTUVAX.BITNET
Days:           Sat, any evening without sessions
Place:          Seafood or Italian is fine

Lee Gleason     gleason@mwk.uucp

Charles Smith   cts@dragon.com
Day:            .not. Thu

Steve Garrett   garrett@pacpwr.uucp

Gerard Newman   gkn@tgv.com

Ehud Gavron     gavron@vesta.sunquest.com
Days:           not Sat or Sun
Place:          A real restaurant with non-paper napkins and everything
From: REGI's <NUNEZ@esevvx.cica.es>
Newsgroups: vmsnet.internals
Subject: (None)
Date: Thu, 15 Oct 1992 17:26: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
12-OCT-1992 12:48:33.64
   1 00:00:00.00
13-OCT-1992 12:48:33.64
@UKCC.uky.edu:MacroMan@WKUVX1.BITNET
gutier@SEVAXU.CICA.ES

Received: from UKCC.uky.edu by ESEVVX.CICA.ES ;  9-OCT-1992 12:48:16.08
Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 3044; Fri, 09 Oct 92 07:47:08 EDT
Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 5377;
 Fri, 09 Oct 92 07: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; Fri, 09
          Oct 1992 06:44:20 CDT
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 2623; Fri,
          09 Oct 92 07:41:54 EDT
Received: from KOPC by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with TCP; Fri, 09 Oct
          92 07:41:31 EDT
Received: from DECNET-MAIL (ARNE@KO) by kopc.hhs.dk (PMDF #3400 ) id
          <01GPQTVHA7W08WW0VG@kopc.hhs.dk>; Fri, 9 Oct 1992 12:40:55 +0100
Date: 09 Oct 1992 12:40:54 +0100
From: Arne Vajhxj <ARNE@ko.hhs.dk>
Reply-To: MACRO32@WKUVX1.BITNET
Subject: Re: C Language question
To: MACRO32 <MACRO32@WKUVX1.BITNET>,
    NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk
X-VMS-To: KOPC::IN%"@cunyvm.cuny.edu:MACRO32@WKUVX1.BITNET"
X-VMS-Cc: IN::"NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-transfer-encoding: 8BIT

> 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?

I think your friend is rigth (a[I][J] would be I*J contigious bytes), but
I can not prove it, but ...

The arguments are:
  1)  As your friend has observed C-compilers tend to do it that way.
  2)  The creative way C lets you manipulate arrays, pointers and
      addresses must somehow assume, that they are stored contigious.
  3)  It is most efficient that way (simpler address calculations).

But to be absolutely certain you will need to check the real sources:
K&R and the ANSI specifications.

                                                          Arne

Arne Vajhxj                             local DECNET:  KO::ARNE
Computer Department                     PSI:           PSI%23831001304030::ARNE
Business School of Southern Denmark     Internet:      ARNE@KO.HHS.DK
From: REGI's <NUNEZ@esevvx.cica.es>
Newsgroups: vmsnet.internals
Subject: (None)
Date: Thu, 15 Oct 1992 14:37: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
15-OCT-1992 00:56:08.90
   1 00:00:00.00
16-OCT-1992 00:56:08.90
@UKCC.uky.edu:MacroMan@WKUVX1.BITNET
gutier@SEVAXU.CICA.ES

Received: from UKCC.uky.edu by ESEVVX.CICA.ES ; 12-OCT-1992 00:56:05.29
Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 1387; Sun, 11 Oct 92 19:54:59 EDT
Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 8828;
 Sun, 11 Oct 92 19:54:58 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; Sun, 11
          Oct 1992 18:55:26 CDT
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 1351; Sun,
          11 Oct 92 19:52:19 EDT
Received: from MVB.SAIC.COM by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with TCP;
          Sun, 11 Oct 92 19:52:07 EDT
Relay-Version: VMS News - V6.0-3 14/03/90 VAX/VMS V5.5; site arizona.edu
    darwin.sura.net!dtix!mimsy!prometheus!media!irscscm!bogart!aldoe!krm!mic!mon
tag ar.com!davidc
X-Newsgroups: vmsnet.internals,vmsnet.misc,comp.lang.c
Subject: Re: malloc() as a user defined function
From: <davidc@montagar.com>
Reply-To: MACRO32@WKUVX1.BITNET
Date: 9 Oct 92 23:30:38 GMT
Organization: Montagar Software Concepts, Plano TX
To: MACRO32@WKUVX1.BITNET
X-Gateway-Source-Info: USENET

In article <Bvv6pH.Gzy@cs.psu.edu>, ytang@red.crayola.cs.psu.edu (Yuan-Ling
 Tang) writes:
>
> Hi netters:
>
>     In programming on dynamic memory allocation, I prefer doing check on
>     every malloc(). I.e.:
>     ...
>     However another problem arises, what if I have many distinct types
>     of memory space to allocate? That is, I can't use the same type in
>     calling my_malloc(). So how can I pass a type to a function?

        Maybe something like this?

#define TALLOC(x)       {int p ; ((p = malloc(sizeof(x)) == NULL) ? \
                                        {perror("Malloc") ; exit(errno) } : \
                                        p ; }

        The sizeof() will resolve the type into the required number of bytes,
such that

        bptr = TALLOC(struct bogus) ;

        will allocate the correct size buffer, while performing the check
(I hope, I haven't tested that macro...)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
David L. Cathey                         |INET: davidc@montagar.com
Montagar Software Concepts              |UUCP: ...!montagar!davidc
P. O. Box 260772, Plano TX  75026-0772  |Fone: (214)-618-2117
From: Arne Vajhxj <ARNE@ko.hhs.dk>
Newsgroups: vmsnet.internals
Subject: Re: Finding a users disk name
Date: 08 Oct 1992 20:00:41 +0100
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

> 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

Newsgroups: vmsnet.internals
From: ecf_stbo@jhuvms.hcf.jhu.edu (Feet...!? You had FEET?)
Subject: Re: Finding a users disk name
News-Software: VAX/VMS VNEWS 1.41    
Organization: The Johns Hopkins University - HCF
Date: Wed, 7 Oct 1992 18:39:00 GMT

In article <1992Oct7.084705.1063@galaxy.gov.bc.ca>, EWILTS@GALAXY.GOV.BC.CA writes...
>The only place the user's default device and directory is stored is in
>SYSUAF.DAT.  Any method you choose for determining the device must have read
>access to this file.  This doesn't require "operator privileges" - READALL,
>SYSPRV, or BYPASS will suffice, or you can install the image you use to get the
>default with privilege so that the end user doesn't need them.

Actually I'm reasonably sure any user can get the information (for 
themselves) by calling $getuai. And I think what this guy was asking
for is as simple as translating the logical name SYS$LOGIN. Not really
much of an internals question.

Tom O'Toole - ecf_stbo@jhuvms.hcf.jhu.edu - JHUVMS system programmer 
Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218 
>Here comes a jet ski.
>weuh weeuhh weeuhh weeuhh WEEUHH WEEUHH WEEUHH WEEUHH weeuhh weeuhh weeuhh weuh
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: vmsnet.internals,comp.os.vms
Subject: Re: VMS shareable images, what's wrong with them?
Date: 7 Oct 1992 09:49:04 GMT
Organization: HST Wide Field/Planetary Camera
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <Bvo7FC.M01@ithaca.com>, garry@ithaca.com (Garry Wiegand) writes:
>The Big 3 that come to mind:
>
>3. Shareable image version numbers should go away.

>The primary purpose in life of #3, the shareable image version
>numbers, is to guard to the transfer table against "accidents". Once
>the transfer table is gone (#2) one can immediately do away with the
>version numbers (or change the default setting to "match any".)
>You'll recall that version-number unpleasantness on Vaxcrtl.exe is
>what got us started on this thread originally.

Er, just how do you think you'll do this?  What the fuck's supposed to happen
when an image has a call to someplace in never-never-land (something that's
guaranteed to happen when an image linked against a later shareable image,
using a new routine, is run against an old one?

Forget your simplistic arm-waving.  Tell us, oh genius, in detailed terms,
exactly how you plan to  avoid this sort of problem.   In other words, jackass: 
PUT UP OR SHUT UP!  I'd be willing to bet you $100 against your $1 that you
can't do it.  C'mon, put your money where your mouth is.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
From: GAVRON@IT.SUNQUEST.COM (Ehud Gavron 602-570-2546)
Newsgroups: vmsnet.internals
Subject: DECUS Get-together for MACRO32:  Monday Night, 8:00PM, Hilton enterance
Date: 9 Oct 92 17:14:58 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Date sent:  9-OCT-1992 10:09:02


        One month ago I asked if any of you wanted to do a get
        together at DECUS one night and go out to dinner.  The
        concensus of the responses is yes.

        People were asked to let me know a preferred time with
        a place if they knew of one.

        Selected day:   MONDAY!!!

        Selected time:  8:00PM

        Selected place: A restaurant (not fast food) to be chosen

        MEETING LOCATION: Right inside the front doors of the Las
                        Vegas Hilton at 8PM on Monday night.


        Thanks to all who responded!

        Ehud


Respondents and data included:
Dan Wing        DWING@UH01.Colorado.EDU
Day:            Sat,Mon,Tue,Thu,Fri
Place:          Any place with dark beer

Bruce Miller    miller@tgv.com

Mars Akerberg   mats@rigel.efd.lth.se

Don Roberts     Don@Beckman.Com
Day:            Best Monday, any evening ok
Place:          Not fast food

Gerald Lester   gwl@cpu.com
Day:            Sunday, Monday
Place:          Food should not be moving *too* fast

Ron Kaledas     RON@LTUVAX.BITNET
Days:           Sat, any evening without sessions
Place:          Seafood or Italian is fine

Lee Gleason     gleason@mwk.uucp

Charles Smith   cts@dragon.com
Day:            .not. Thu

Steve Garrett   garrett@pacpwr.uucp

Gerard Newman   gkn@tgv.com

Ehud Gavron     gavron@vesta.sunquest.com
Days:           not Sat or Sun
Place:          A real restaurant with non-paper napkins and everything
Xref: sparky vmsnet.internals:1420 comp.os.vms:16261
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.internals,comp.os.vms
Subject: Re: VMS shareable images. MULTICS, AS-400, NT?
Date: 8 Oct 92 12:45:40 GMT
Distribution: world,local
Organization: Mitech Corporation, Concord MA

In article <7OCT199210492045@carat.arizona.edu>, jms@carat.arizona.edu (A virtually vegetal non-entity) writes:

> about flaming, and technical info, and Ehud's last message ...

In fact, I found Ehud's message to be a flame worth keeping around.

At MIT we used to call something with the right tone and technical 
content a "FLAME."

If there was not sufficient technical content then the thing
would not even be -elevated- to deserve the term "flame" and
instead would be considered mere whining, or worse.

----------

Flame:

The real problem today is that there is no technical respect for
operating systems, period. Of what benefit would it have been
to DIGITAL to make VMS truly call-oriented across all functionalities
at the DCL level (that is, there would no longer be -any- "executable"
files that are activated by the RUN command, instead every functionality
invoked by the command interpreter would come from essentially a kind
of LINK/SHARE'd object, and there would be a more general kind
of LIB$FIND_IMAGE_SYMBOL with the ability to deactivate images no
longer needed). In short, give us something of Multics circa 1975, only
better?

Would that have helped in DIGITAL in the marketplace? 
Is Microsoft "NT" going provide something like that?

All the emphasis is on the features of the SUBSYSTEM or worse, the
graphical user interface. 

And heck, if you are good enough, and can make kernel mods if needed,
you can get just about any kind of application subsystem running
in anything, even UNIX.

A possible exception to this flame might be the IBM AS-400 system. 
Now perhaps IBM was willing to invest in making the base operating 
system provide better functionality in areas such as dynamic linking and object
management because the extra complexity of such a thing makes
it a lot more difficult to reverse engineering and connect into,
in addition to enforcing a certain quality and consistency
in all applications that are done in the environment provided.

Obviously another big exception to this is all the volume shadowing
and vaxcluster and other stuff associated with VMS. That kind of thing
goes a long way to making the operating system responsible for providing
a consistent and robust environment in which an application can run.
But still, it isn't as iron-clad automatic and unavoidable as what
was available in old Multics or AS-400 land.

But then again, all this could be provided in the SUBSYSTEM itself.
e.g. private journalling and backup activities in a database implementation.

-gjc
Newsgroups: vmsnet.internals,comp.os.vms
From: winalski@adserv.enet.dec.com (Paul S. Winalski)
Subject: Re: VMS shareable images, what's wrong with them?
Reply-To: winalski@adserv.enet.dec.com (Paul S. Winalski)
Organization: Digital Equipment Corporation, Nashua NH
Date: Sat, 10 Oct 1992 19:40:31 GMT


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: REGI's <NUNEZ@esevvx.cica.es>
Newsgroups: vmsnet.internals
Subject: (None)
Date: Thu, 15 Oct 1992 16:30: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
13-OCT-1992 01:59:10.29
   1 00:00:00.00
14-OCT-1992 01:59:10.29
@UKCC.uky.edu:MacroMan@WKUVX1.BITNET
gutier@SEVAXU.CICA.ES

Received: from UKCC.uky.edu by ESEVVX.CICA.ES ; 10-OCT-1992 01:59:08.23
Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2)
   with BSMTP id 6855; Fri, 09 Oct 92 20:58:02 EDT
Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 9814;
 Fri, 09 Oct 92 20:58:01 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; Fri, 09
          Oct 1992 19:50:39 CDT
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 6607; Fri,
          09 Oct 92 20:37:34 EDT
Received: from MVB.SAIC.COM by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with TCP;
          Fri, 09 Oct 92 20:37:32 EDT
From: <gjc@mitech.com>
Reply-To: MACRO32@WKUVX1.BITNET
X-Newsgroups: vmsnet.internals
Subject: Re:  C Language question
Date: 9 Oct 92 14:32:00 GMT
Organization: Mitech Corporation, Concord MA
To: MACRO32@WKUVX1.BITNET
X-Gateway-Source-Info: USENET

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
Xref: sparky vmsnet.internals:1406 comp.os.vms:16182