HDTenEightyP/NetNews huggingface dataset:
From: jlnance@eos.ncsu.edu (JAMES LEWIS NANCE)
Subject: Re: What is meant by: double A[n,m]?
Originator: jlnance@kelley.ece.ncsu.edu
Reply-To: jlnance@eos.ncsu.edu (JAMES LEWIS NANCE)
Organization: North Carolina State University, Project Eos
Date: Wed, 18 Nov 1992 13:30:02 GMT


In article <TORSTEIN.92Nov18125146@itekiris.kjemi.unit.no>, torstein@itekiris.kjemi.unit.no (torstein hansen) writes:
|> 
|> As a newcomer to C, previously programming in Pascal, I used the
|> following declaration in one of my programs:
|> 
|> double A[n,m];
|> 
|> I assumed (erronously) that this would give a n by m matrix. But
|> obviously, it didn't.  But the compiler never gave any errors or
|> warnings, and using 
|> 
|>   A[rownumber,colnumber]=some_value;
|>  
|> was also accepted by the compiler.  I'm not asking for the correct 
|> way to define an array, I found that out quickly, but what is meant 
|> by A[n,m]?  It seems like the compiler just ignores the n and makes 
|> it A[m].  This is also the case when assigning values to the array.


|> Can somebody enlighten me in this matter?  I couldn't find anything
|> about it in any of the C books I have.  If double A[n,m] is illegal,
|> shouldn't I get a warning at least?
|> 
|> Has it something to do with the comma operator, discarding the first
|> value inside the braces?

I have made this mistake also.  I believe that it does have to do with the
comma operator, which would make the expressions 2,2 == 2.  The correct way
to define your array would be a[n][m].


Jim Nance
From: arj@cam-orl.co.uk (Andy Jackson)
Newsgroups: comp.lang.c
Subject: Re: cvs
Date: 18 Nov 92 13:50:25 GMT
Organization: Olivetti Research Ltd, Cambridge, England.
X-Newsreader: TIN [version 1.1 PL6]

Chris Flatters (cflatter@nrao.edu) wrote:
: 
: CVS is distributed by the Free Software Foundation and will be available from
: most sites that have GNU software (eg. prep.ai.mit.edu).
: 
: You will also need RCS (available from the same sites).
: 
Does anybody know of a port that runs on MS-DOS ?

			Andy..

-- 
--------------------------------------------------------------------------
  Andy Jackson - arj@cam-orl.co.uk - phone 0223-343308 - fax 0223-323542
    Olivetti Research, 24a Trumpington Street, Cambridge, UK, CB2 1QA
--------------------------------------------------------------------------
Newsgroups: comp.lang.c
From: jrv@truth.mitre.org (Van Zandt)
Subject: Re: Looking for public domain math software
Organization: The MITRE Corp., Bedford, Ma.
Date: Mon, 23 Nov 1992 18:18:38 GMT

In article <98834@netnews.upenn.edu> freeman@gradient.cis.upenn.edu (Jon Freeman) writes:
>I know that someone on this newsgroup maintains a list of public
>domain C code for doing things like linear programming, matrix
>decomposition, etc.  I don't need any of this code, but I told a
>colleague of mine about it and he does.  Could someone please
>email me the latest copy of this list or tell me where I can ftp
>it?

    Netlib is a system for distribution of mathematical software
    by  electronic  mail.  To get information about Netlib, mail
    the following one-line message to netlib@ornl.gov.
 
                send index

...from their introduction.

                     - Jim Van Zandt <jrv@mbunix.mitre.org>

Newsgroups: comp.lang.c
From: mjs@hubcap.clemson.edu (M. J. Saltzman)
Subject: Re: Reasons for using C vs. Fortran or vic
Organization: Clemson University, Clemson SC
Date: Sun, 15 Nov 1992 22:40:10 GMT

In article <1992Nov15.201555.20678@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
>In article <1992Nov13.162451.13049@zia.aoc.nrao.edu>, cflatter@nrao.edu (Chris Flatters) writes:
>
>> Storing arrays by column or by row doesn't make any difference
>> whatsoever to the speed of matrix operations: it is merely a notation
>> change.
>
>This is true only in the abstract.  I have experienced (not just heard
>about) multiple orders of magnitude speed differences, because going
>through arrays "the wrong way" had catastrohpically bad VM behavior:
>essentially, every access involved a page fault.  Doing it "the right
>way" stepped through VM in a nice sequential way, with minimal paging.

Note that you do have to adjust the details of the access pattern to
match the storage patter, in order to not suffer performance penalties
because of lack of locality.  For example, if you are storing matrices
in row-major order, you should perform matrix-vector multiplication as
a sequence of inner products of the vector with the rows of the
matrix:

	/* Compute y = y + Ax, accessing A in row-major order */

	for i = 1 to m do
	  for j = 1 to n do
	    y[i] = y[i] + A[i][j] * x[j]

If your matrices are stored in column-major order, you should
perform matrix-vector multiplication by summing scalar multiples of
the columns of the matrix:

	/* Compute y = y + Ax, accessing A in column-major order */

	for j = 1 to n do
	  for i = 1 to m do
	    y[i] = y[i] + A[i][j] * x[j]

Thus, there is a "right way" for either storage pattern, but they are
different.

Now, if you are doing matrix-matrix multiplication for matrices stored
in column-major order, the "right way" is a natural extension of the
second algorithm above (i.e., C = AB is computed by multiplying A by
successive columns of B).  If your matrices are in row-major order,
the interpretation of the appropriate sequential-access algorithm is
not so straightforward.  I conjecture that this is why Fortran
designers chose column-major storage for matrices.  Once that's done,
the extension to more than two dimensions is pretty much dictated.
-- 
		Matthew Saltzman
		Clemson University Math Sciences
		mjs@clemson.edu
From: lpeters@postmaster@hq.af.mil (Leslie D Peters)
Newsgroups: comp.lang.c
Subject: Re: *** IMPORTANT DISCOVERY ***
Date: 20 Nov 92 15:10:41 GMT
Reply-To: lpeters@marge.hq.af.mil
Organization: 7th Communications Group

In article <1992Nov19.005209.3791@spock.UUCP>, kurgan@spock.uucp (Andrew Twyman) writes:
|> In article <1992Nov18.235959.3071@spock.UUCP> aorpha@spock.uucp (Andreas Orphanides) writes:
|> >In article <1992Nov16.221156.18458@spock.UUCP> kurgan@spock.uucp (Andrew Twyman) writes:
|> >>In article <1992Nov13.210911.3086@msuinfo.cl.msu.edu> knaggs@cps.msu.edu (Scott A Knaggs) writes:
[ utter waste of electrons removes ]
|> >>Not only is this too sick to be on rec.humor (which isn't necessarily bad),
|> >>but it's nauseating and DUMB!  Keep it out of my face.  You're even more of a
|> >>pervert than I am, and that's a sick thought.
|> >>-- 
|> >>-------------------------------------------------------------------------------
|> >>|  -"I have something to say.  It's better to burn out, than to fade away!"-  |
|> >>|                          -* THERE CAN BE ONLY ONE *-                        |
|> >>kurgan@choate.edu--------------------------------------------------------------
|> >
|> >Well, my aarch-nemisis, i see that in one field we agree.
|> >
|> >PERVERTS SHOULD BE KEPT OFF THE NET. man, that paragraph is grosser than kurgan's (in real life) face!
|> 
|> Pitiful Ramirez.  I had his head and took his woman before the day was out!
|> -- 
|> -------------------------------------------------------------------------------
|> |  -"I have something to say.  It's better to burn out, than to fade away!"-  |
|> |                          -* THERE CAN BE ONLY ONE *-                        |
|> kurgan@choate.edu--------------------------------------------------------------
If this thread keeps up, I'll be out of grenades and will have to
break out the tactical nukes.
-- 
/============================================================================\
|                    ___                     |                               |
|       ___....-----'---`-----....___        | I haven't lost my mind --     |
| =========================================  |                               |
|        ___`---..._______...---'___         |  it's backed up on            |
|       (___)      _|_|_|_      (___)        |   tape somewhere.             |
|         \\____.-'_.---._`-.____//          |                               |
|           ~~~~`.__`---'__.'~~~~            | lpeters@marge.hq.af.mil       |
|                   `~~~'                    |                               |
\============================================================================/
Newsgroups: comp.lang.c,comp.os.vms
From: flower@donald.etdesg.trw.com (Rick Flower)
Subject: Looking for "C" Source Line Counter
Summary: see above..
Originator: flower@donald
Keywords: C Counter VMS Unix
Organization: TRW Inc., Redondo Beach, CA
Date: Tue, 17 Nov 92 22:22:12 GMT

Hi...

	I'm looking for a code line counter for "C".. I'm guessing that there
is one out there somewhere!  Ideally, I'm looking for one that runs on a 
VAX/VMS system, but if the code is for Unix, I'd be more than willing to port
it to the VAX environment (not the first or last time!)..  If you know of one
floating around somewhere, please e-mail me what the name is or where I can
find it, etc..  Any help is appreciated!

-- Rick
Xref: sparky comp.lang.c:16762 comp.std.c:3031
From: clive@x.co.uk (Clive Feather)
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: Idle Questions about ANSI C
Date: 18 Nov 92 12:26:31 GMT
Followup-To: comp.std.c
Organization: IXI Limited, Cambridge, UK

[Crossposted to comp.std.c - followups there please]

In article <1992Nov14.162633.13199@taumet.com> steve@taumet.com (Steve Clamage) writes:
> pjh@mccc.edu (P. J. Holsberg) writes:
>> 1) Is "size_t" ever not the same as "unsigned int"? If so, in what situation?
> If the address space is large but ints are small, size_t will be unsigned
> long.  If address space is small but ints are large, you might want to
> make size_t an unsigned short.  I've seen implementations like the first
> case.  The second case seems unlikely.  Both could be Standard-conforming.

As far as I can tell, the second case is Standard-conforming. However,
the Rationale says (4.1.6):
| All library prototypes are specified in terms of the "widened" types:
| an argument formerly declared as char is now written as int. This
| ensures that most library functions can be called with or without a
| prototype in scope.
(and then goes on to point out that varargs functions need a prototype).

However, this is not true for malloc if size_t is unsigned short, and:

    extern void *malloc ();

causes undefined behaviour.
-- 
Clive D.W. Feather     | IXI Limited         | If you lie to the compiler,
clive@x.co.uk          | Vision Park         | it will get its revenge.
Phone: +44 223 236 555 | Cambridge   CB4 4RZ |   - Henry Spencer
Fax:   +44 223 236 550 | United Kingdom      |
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: order of 'external' declarations
Date: 21 Nov 92 17:36:28 GMT
Organization: AND Software BV Rotterdam

In article <P438VUC@gwdu03.gwdg.de> moeller@gwdgv1.gwdg.de writes:
|I've just come across a supposedly ANSI-compatible C compiler that chokes on
|
|	func()
|	{
|		extern char *var;
|		...
|	}
|
|	char *var = "some text";
|
|With functions, this kind of "forward" declaration is quite normal,
|so I think it should also be ok with data (for which you have 
|to explicitly use 'extern'). Any opinions?

Yes, I have two opinions: you are right and your compiler is wrong.
It is perfectly legal to use the `extern' storage class specifier
inside a function. It simply tells the compiler that the declared
argument is defined somewhere else, _outside_ the function block scope. 

kind regards,

Jos aka jos@and.nl
From: conor@lion.inmos.co.uk (Conor O'Neill)
Subject: Re: Help me track down memory leakage
Reply-To: conor@inmos.co.uk (Conor O'Neill)
Organization: INMOS Limited, Bristol, UK.
Date: Thu, 19 Nov 1992 16:14:11 GMT

In article <BxuLIr.DK@rice.edu> abuhr@owlnet.rice.edu (Aaron M. Buhr) writes:
>     I've inherited a very large C program that I am trying to maintain and
>expand, and I've come to the point where I HAVE to find out where the
>program's leaking memory.  The program starts out with about 7MB virtual
>mem usage, 6MB real, and grows over the course of 6-8 hours to around 20MB
>virtual, 10MB real.  The program uses straight malloc() and realloc() calls.
>I don't know where or how to start trying to track this down.  Any help
>would be greatly appreciated.  Email is preferred, but I'll try to watch
>the posts to this group as well.  Much thanks in advance.

The 'purify' system, which I used on a Sun 4, seems very good.

It is very easy to use - you just edit your 'link' line in your makefile.
It reports stuff such as some illegal pointer accesses, eg accesses
to free-d memory, and also gives a list of all memory which is still
allocated at program termination, and tells you where it was malloc-ed.




---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk		US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: const char *p == char const *p ?
Date: 16 Nov 92 10:32:00 GMT
Organization: AND Software BV Rotterdam

In article <1992Nov16.010820.26757@cs.tu-berlin.de> jutta@opal.cs.tu-berlin.de (Jutta Degener) writes:
|bonak@herky.cs.uiowa.edu (Esmail Bonakdarian) writes:
|> Is "char const *p" equivalent to "const char *p"?
|
|Yes.  They are both pointers to constant character; you may
|change the pointer, but not the character it points to.
|
|Some programmers prefer "char const *" to "const char *".
|They argue that C declarations are read "inside out":
|
|   char const * p ;
|                ^     p is a
|              ^              pointer to
|        ^^^^^                           constant
|   ^^^^                                          char
|
|But that's just a matter of style.

Sorry, you're making a mistake, `const char * p' is _not_ equivalent
to `char * const p'. The first declaration reads: `there is a character
constant, and p points to it', while the second one reads: `this is 
a character pointer p and it is a constant.' 

Using `char * const p' without an explicit initialization is quite
silly, because assigning a value to p later on in the code, is
not allowed. I do agree that the syntax is a bit confusing ...

kind regards,

Jos aka jos@and.nl
Xref: sparky comp.lang.c:16750 comp.software-eng:4383
From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.lang.c,comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Date: 18 Nov 92 17:16:06 EST

In article <1992Nov18.121328.19775@icf.hrb.com>, tpd@icf.hrb.com (THOMAS P. DONNELLY) writes:
> In article <books.110.0@fsunuc.physics.fsu.edu>, books@fsunuc.physics.fsu.edu (Roger Books) writes:
>> In article <1992Nov17.091220.9284@iccgcc.decnet.ab.com> kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo) writes:
>>>
>>>IMHO, there is probably no better background for SE than physics.  Why? 
>>>Problem solving.  Experimental techniques.  Basic understanding of the
>>>strangeness of the universe.  All useful.  
[...]
>> If it
>> involves dropping a kludge in to make it work they do and then forget
>> about it.  This may be different with theorists but the experimentalists
>> I work for don't write maintainable code.
> Hmm... isn't this the difference between the scientist, who constructs a
> one-shot apparatus to increase the knowledge of the field, and the engineer,
> who builds machinery to be used many times?  
What have you hired the person to do, independent of their background? Why not
treat the creation of maintainable code as a scientific (or engineering)
problem and develop a permanent solution?
[...]
> In short, if you want code to be maintained, hire a software engineer
> (programmer?).

I will gladly hire any one of a number of people who will be able to perform
the task that I set out for them.  Im my own experience, I have worked with a
number of physicists/EE's who, on average, produced more reliable, more
maintainable code than programmers working in the same commercial
environment on the same products.  This is *not* to say that I do not know and
respect a number of SE's and CS's who do good work.  Have I done a numerical
study recently?  No.  It is only my experience and opinion.  I will still look
at  skills when I am filling a job.  I would just make sure to expand my
horizons to include other backgrounds maybe not traditionally thought part of
good software engineering.

George Kambic
sd
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Newsgroups: comp.lang.c
Subject: Re: LHS Casting
Date: 16 Nov 92 15:23:10 GMT
Organization: SAS Institute Inc.
Originator: sasghm@theseus.unx.sas.com


In article <1992Nov13.050054.28251@druid.uucp>, darcy@druid.uucp (D'Arcy J.M. Cain) writes:
|> I came across some of the ugliest code I have seen in a long time recently.
|> At one point there is a pointer to char that is declared as a pointer to
|> int.  To get an address within this block of bytes the programmer does:
|> 
|> (int *) charptr = intptr + (OFFSET/2);
|> 
|> Well of course this is bad.  The FAQ (question 2.13) shows another case

It's not only bad, it is a violation of ANSI.  See Section 3.3.4,
note 41 ("A cast does not yield an lvalue. ...")  Some older C
compilers used to accept this nonsense.  I cannot lay my hands on
a precise reference at the moment, but there was an issue of _Dr.
Dobbs_ some time in '85 or '86 in which a paper (to the ANSI C
committtee) written by Francis Lynch and me was reprinted almost in
its entirety as part of a column on the standardization of C.  In
that paper a number of compelling arguments are offered against
allowing a cast to be an lvalue.  If you can find the appropriate
issue of the magazine, you might be interested in these arguments.

-- 
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c
Subject: Re: Is this ANSI?
Date: 20 Nov 92 23:03:04 GMT
Article-I.D.: alice.24262
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ

In article <By0vu2.7AF@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:

> I think "does not allow that technique" is a little strong.  What you
> *can* do is

	struct FM
	{
	   short data_len;
	   char  data[1];
        };

	struct FM *fmptr;

	fmptr = malloc( sizeof(struct FM) + ??? );

> where the ??? is the number of bytes of your data minus 1.  Some may
> regard this as "impure", but it is not forbidden by the standard and
> is eminently portable.

Oh, really?  Can you give me concrete evidence that the C standard allows it?

More specifically, after executing the code above, can you give me
evidence that referrint to fmptr->data[i] is allowed when i>1?
-- 
				--Andrew Koenig
				  ark@europa.att.com
Newsgroups: comp.lang.c
From: johnd@ducvax.auburn.edu
Subject: memory function needed
Organization: Auburn University, AL
Date: Sun, 15 Nov 1992 16:44:57 GMT


I have a nasty little problem and I was wondering if someone
might be able to help me out.  I am writting a program in C on the
VAX.  I need to "monitor" the amount of memory I have available at
anytime.  I would like to have a function like -- free_memory_left().

I have seen the lib$stat_vm function which will give me the amount
of memory allocated (if I could get it to work - access violations??)
If I also new my max virtual memory amount, I would have it!

Is there a library call that will give me what I needed?

Also, is there something special I have to do use the 
lib$stat_vm (or any runtime library) function?

Thanks,
John

jdennis@eng.auburn.edu
Newsgroups: comp.lang.c
From: singg@alf.uib.no (Kurt George Gjerde)
Subject: Wait for child
Organization: University of Bergen, Norway
Date: Mon, 16 Nov 92 12:27:25 GMT


On Unix, how can I have a process wait for it's child process to do something
(not terminate).

I've tried using sigpause (couldn't find pause) in the parent process, and 
having the child to send SIGCONT, but that didn't work...

Any ideas?



( Right now it works with the parent constantly checking the existance of a
  file. When the child removes the temp-file, the parent continues... 
  THIS SLOWS DOWN THE SYSTEM! )

K.

Newsgroups: comp.lang.c,comp.software-eng
From: pdh@netcom.com (Phil Howard )
Subject: Re: Will we keep ignoring this productivity issue?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Mon, 16 Nov 1992 09:16:43 GMT

mat@mole-end.matawan.nj.us writes:

>Echoing my own favorite refrain: There is no circuit theory for software.
>The theoretical computer sciences are closer to advanced Fields and Waves
>or Communication Theory: essential in the long run, but not a first-order
>theory describing what you work with continually.

The Computer Scientists are too busy trying to get people AWAY from
thinking about the bits and bytes (and towards the abstract) to get
people to properly understand how to deal with the bits and bytes.

In EE you START from the bottom and work your way up.  You learn to
understand the building blocks.  Computers SHOULD be taught the same
way.  In fact I am awfully tempted to say that the circuit theory and
digital circuits courses should be taught to even though wanting to
become programmers.  At least some machine language should be.


>An Engineering School education is a special blend of theory and practice,
>one I feel quite privileged to have enjoyed.  It's been ten years since I
>got my degrees, but I see no evidence that the software world has as yet
>anything like it.

NOTHING like it... and I didn't even have to go through engineering to
know that.
-- 
/***********************************************************************\
| Phil Howard  ---  KA9WGN  ---  pdh@netcom.com   |   "The problem with |
| depending on government is that you cannot depend on it" - Tony Brown |
\***********************************************************************/
Newsgroups: comp.lang.c
From: pebi@aem.umn.edu (Peter A. Bidian)
Subject: the abs() function in C
Organization: University of Minnesota
Date: Fri, 20 Nov 1992 01:37:04 GMT


Isn't abs(-2)=2 in C?
I always get 0.

Confused!

Peter