HDTenEightyP/NetNews huggingface dataset:
From: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: Re: Memory Info.
Organization: VideOcart Inc.
X-Newsreader: Tin 1.1 PL3
Date: Fri, 20 Nov 1992 20:23:18 GMT

vugranam@pike.ee.mcgill.ca (Vugranam Chakravarthy Sreedhar) writes:
: 
: Given a pointer to a object that has been previously allocated using
: one of the allocation routine, how can I get the
: size of the object.
: 
: For example,
: 
: char *c;
: long  x ; 
: 
:  c = (char *) malloc (100) ;
:     .
:     .
:     .
: 
: x = mem_size(c) ;   /* x is block size of c, which in this case is 100 */
: 
: 
: I want to use this to keep track of memory statistics. Now what I do is
: to pass the size to my memory routines. Like
: 
: int *mymalloc(size) ;  /* this is easy */
: 
: int myfree(char *, long size)   /* I don't like this !!*/
: 
: Thanks
: 
: 
: Sreedhar

   Try using a static array of structures that have the pointer and the size
of it in each structure member. Then when you pass the pointer to the routine
that returns the size of the area pointed to, all you have to do is search
the array for the pointer and return the value associated with it.

BTW, myfree() is useless. When you free a pointer you don't need to give
the size. Unless this routine subtracts the size from the current total
of memory allocated.

Try the structure array, make it static in the module, and make the module
contain only the my_malloc, my_free, and maybe a routine called my_mem_usage
that will total up the values in the array and return it.

dave fuller  
dfuller@portal.hq.videocart.com
From: isc40038@nusunix1.nus.sg (LIM FANG HOW)
Newsgroups: comp.lang.c
Subject: Questions on kill signal
Date: 19 Nov 92 09:36:05 GMT
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]

How to implement a process that when receives a kill signal from the
shell, will write some characters into a text file ? 
 
P.S :
     This process must be able to receive the kill signal at any point.....
Newsgroups: comp.lang.c
From: jgerth@magnus.acs.ohio-state.edu (Jeffrey D Gerth)
Subject: Reading data into an array
Keywords: array
Organization: The Ohio State University
Date: Wed, 18 Nov 1992 22:39:52 GMT

Hello... does anyone have any suggestions on how to read a numerical data file 
into a three dimension array?....thanks
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: Virtual memory Management Systems
Date: 20 Nov 92 10:19:29 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <1992Nov18.081123.29057@di.unipi.it>, ntranqu@caticsuf.cati.csufresno.edu (Nico Tranquilli) writes:
> In article <1992Nov17.143327@gese.ge14.mdadv.gv.at> Petzi Schweda, sca@gese.ge14.mdadv.gv.at writes:

> Perhaps I should have asked : "What is the name of HARDWARE devices
> which allocate virtual memory on disks whenever the internal memory
> become full ?

This is (usually) done in OS software, not in hardware.  Typically, the
OS will set up the MMU [memory management unit] so that all pages are
valid, then when it wants to make room, it will write a page out to
disk and reset the MMU so the page is invalid.  Upon next access to
that page, the MMU will generate a trap to the OS, which does whatever
is appropriate (typically reading the page back in, resetting the MMU,
and resuming the interrupted process).

In short, someone else's answer - CPUs - is, while rather flippant,
nonetheless basically correct.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: kdq@quest.UUCP (Kevin D. Quitt)
Newsgroups: comp.lang.c
Subject: Re: Reasons for using C vs. Fortran or vic
Date: 16 Nov 92 00:57:56 GMT
Article-I.D.: quest.0i5auB1w165w
Reply-To: srhqla!quest!kdq
Organization: Job quest  (805) 251-8210,  So Cal: (800) 400-8210

mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
> In article <1992Nov13.162451.13049@zia.aoc.nrao.edu>, cflatter@nrao.edu (Chri
> > 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.

    You've misunderstood.  *Storage order* makes no difference, as long
as the *access order* matches.  What you've described is what happens
in any language when the wrong order is used.


 _
Kevin D. Quitt      96.37% of all statistics are made up.     srhqla!quest!kdq
Newsgroups: comp.lang.c
From: bonak@herky.cs.uiowa.edu (Esmail Bonakdarian)
Subject: const char *p ==  char const *p ?
Date: Sun, 15 Nov 1992 16:29:12 GMT
Reply-To: bonak@herky.cs.uiowa.edu (Esmail Bonakdarian)
Organization: U of Iowa, Iowa City, IA

I looked in the faq file but didn't find the answer for this exact question.

MY QUESTION IS:

  char const *p 

equivalent to

  const char *p    ?


I.e, both pointers can be modified, but can not modify the contents at 
the location they are pointing to (correct?)

I  understand that
  char *const p 
is a constant pointer, i.e., the pointer can not be modified, but
the contents of the location it is pointing to can.

Thanks for clearing up my question

Esmail
Newsgroups: comp.lang.c
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: Is this ANSI?
Organization: Sequoia Peripherals, Inc.
Date: Mon, 23 Nov 92 19:58:04 GMT

>
>I asked my C mentor about this once, and he pointed out that the compiler is
>free to store the members of the structure in any order.  Thus the compiler 
>could store data[1] in memory before it stores data_len.  Then if you wrote
>to data[1] you would clobber data_len.  

Your mentor was wrong. The ANSI standard requires structs to be
laid out with the fields in the correct order. The only leeway that
is allowed in setting up structs is that the compiler can put padding
between fields in order to make sure the fields are aligned properly.
There is no leeway to store fields in an order different from how the
user defined the struct.

As far as I know all pre-ANSI compilers worked this way as well.



-- 
Dave Eisen                               Sequoia Peripherals: (415) 967-5644
dkeisen@leland.Stanford.EDU              Home:                (415) 321-5154
       There's something in my library to offend everybody. 
          --- Washington Coalition Against Censorship
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Newsgroups: comp.lang.c
Subject: Re: Is this ANSI?
Date: 20 Nov 92 16:15:37 GMT
Organization: SAS Institute Inc.
Originator: sasghm@theseus.unx.sas.com


In article <24238@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
|> In article <9eRguB1w165w@quest.UUCP> srhqla!quest!kdq writes:
|> 
|> >     Here is (a simplified version of) the struct that the compiler
|> > calls an error:
|> 
|> > struct FM
|> > {
|> > 	short	data_len;
|> > 	char	data[];        /*  This line is the kicker  */
|> > };
|> 
|> >     As I recall, ANSI says this is legal, with sizeof( struct FM) is 2 
|> > bytes, and offsetof( struct FM, data) is 2.
|> 
|> I don't think you recall correctly.  If nothing else, there is no
|> requirement that sizeof(short) <= 2.  Moreover, since every object,
|> including members of structures, must have nonzero size, the line
|> in question would have to allocate at least one element.  I would
|> therefore expect that if I hunted through my copy of the Standard,
|> I would find that this fragment is indeed illegal.

It sure is illegal.  Some compilers (our mainframe compiler, for example)
allow this as an extension.  It's not a good idea to code this even if
it is permitted.

|> I'm not going to bother to hunt, though, because I think your question
|> conceals a more important question that I can answer much more easily.
|> The point is to ask why you're trying to do this in the first place.
|> 
|> That is, why bother with what looks like an array with no elements?
|> What use is it?  The only answer I can think of is that you're intending
|> to allocate `extra' memory and then subscript off the end of the array --
|> and the standard definitely does not allow that technique, period.

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.  Why would you want to do this?  Well, it
can really reduce the number of malloc() calls and hence the
function call overhead in general.  I have achieved quite measurable
performance improvements on some systems with this technique.

It's not so hot if you ever want to *change* the size of the data
array, free it, etc.  If you are going to do ugly stuff, you need
to think about it carefully and weigh the benefits against possible
future costs.
-- 
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: clive@x.co.uk (Clive Feather)
Newsgroups: comp.lang.c
Subject: Re: & of array - what does ANSI specify for resulting value?
Date: 18 Nov 92 08:46:37 GMT
Organization: IXI Limited, Cambridge, UK

In article <1992Nov13.204451.26101@eagercon.com> eager@eagercon.com writes:
>In article 1901@ils.nwu.edu, engber@ils.nwu.edu (Mike Engber) writes:
>> int foo[3];
>> I know ANSI specifies the type of &foo will be an int**, how about
>> the value? Is it unspecified - or - &foo[0].
> No, ANSI specifies that &foo is illegal.

No, ANSI specifies that &foo is perfectly legal. It has type "int (*)[3]"
(pointer to array of 3 ints).

> foo is converted to a value which is the address of the first element of
> the array.

Not in this context, it isn't.

> Some compilers will give you a warning and interpret &foo as foo.  

Some old compilers will. Some old compilers will give an error. All
ANSI/ISO compilers will accept this.

[Flame on]
*Please* stop posting erroneous information about the ANSI/ISO standard
in this group - I think this is about the third time you've done this
recently - until you've checked it.
[Flame off]

-- 
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      |
Newsgroups: comp.lang.c
From: eager@eagercon.com (Michael J. Eager)
Subject: Re: Can you program in C?
Reply-To: eager@eagercon.com
Organization: Eager Consulting
Date: Thu, 19 Nov 1992 17:36:31 GMT

In article 675CEA80@vms.csd.mu.edu, 2644danticoj@vms.csd.mu.edu () writes:
>Greetings--
>
>My name is Cetera and I am new to this network. I am anxiously awaiting
>graduating Marquette this December, but there is an obstacle in my way. I must
>first pass this math class in which I must program in C. I don't know this
>language, and now must write several programs before the end of the year. The
>course teaches data structures, which I have no problems understanding.
>However, all homework is programmed in C and because of an adminstrative
>loop-hole, I was enrolled in the class with no knowledge of the needed
>programming language. So, can you help me write these programs, thereby
>allowing me to graduate and go on to serve my country as an officer on a
>nuclear submarine? Please???? My future depends on it. By the way, I will be
>using a UNIX machine with a STUDSYS compiler. Help!!!!!!!!!!!!!!!!!!!!!


Let's clarify a few things:
  1) You were enrolled in the class against your will, as result of an 
     administrative loophole, in spite of the fact that you don't have the
     required prerequisites?
  2) You absolutely don't have time to sit down with a good C text book and
     learn the language?
  3) You cannot drop the class and take it again next term, enrolling in the
     prerequisite course this term?
  4) You believe that everyone else has adequate free time to write three
     programs plus an extra credit for someone they have never met? 
  5) You think that "depending on the kindness of strangers" is an appropriate
     method of doing your class work and receiving a degree?
  6) You believe that the code of ethics, requiring that you turn in only work 
     which you have performed yourself, which your school surely requires is a 
     pointless exercise in misguided philosophy?
  7) You believe that plagurism and representing other people's work as your
     own exemplifies the best that can be expected of an officer in the navy?
  8) You believe that laws against fraud apply only to other folks?
  9) You believe that your future depends on conning other people into doing
     your work for you in this class and perhaps in every other class?



---
Michael J. Eager		Michael.Eager@eagercon.com
Eager Consulting		(415) 325-8077 
1960 Park Boulevard, Palo Alto, CA 94306-1141

Newsgroups: comp.lang.c
From: bcochell@ws14.ips.iacd.honeywell.com (Bill Cochell)
Subject: Re: Multiple &'s in an if statement
Keywords: &
Reply-To: bcochell@ips.iacd.honeywell.com
Organization: Honeywell Industrial Automation and Control
Distribution: comp.lang.c
Date: Mon, 23 Nov 92 18:47:45 GMT

duh,

My apologies for asking such a dumb question. Of course I meant to use &&
instead of &.

Iv'e been on a temporary assignment for 4 months and haven't done any
coding in that time. It's amazing how much I forgot in such a short time.

To all who replied (and will reply) via email and the net thanks.

-- 
Bill Cochell   | bcochell@ips.iacd.honeywell.com   | (602) 436-4832
Honeywell      | Industrial Automation and Control |
Mail Stop:  G1 | 16404 North Black Canyon Highway  | Phoenix, AZ  85023
Newsgroups: comp.lang.c,comp.sources.wanted,comp.unix.programmer,comp.sys.transputer
From: ahoekstr@cs.utwente.nl (Andre D. Hoekstra)
Subject: lex/yacc specification of Occam-2 wanted
Followup-To: poster
Reply-To: A.D.Hoekstra@wb.utwente.nl
Organization: Twente University, Dept. WB/WA (NOT cs)
Date: Thu, 19 Nov 1992 12:43:26 GMT

We are planning to do some automated code-fondling on Occam-2 source code.
Therefore we need a lex/yacc description of Occam-2. This is not a so
complicated task, I suspect, so I don't like to reinvent the wheel (Call me
lazy if you like). 
Anyone who has done this before? Please send pointers or sources through
e-mail to A.D.Hoekstra@wb.utwente.nl.

aTdHvAaNnKcSe!

Andre--
-- 
There is no reason for any individual to have a computer in    | Andre Hoekstra
their home. (Ken Olson, Ex-President Digital Equipment, 1977)  | Enschede -- NL
Newsgroups: comp.lang.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Is this ANSI?
Organization: SoftQuad Inc., Toronto, Canada
Date: Sat, 21 Nov 92 12:50:38 GMT

> > Here is (a simplified version of) the struct that the compiler
> > calls an error:
> 
> > struct FM
> > {
> > 	short	data_len;
> > 	char	data[];        /*  This line is the kicker  */
> > };

I attempted to email an answer to the poster, also pointing out
that his Reply-To line was invalid.  The mail actually did get to
his system, or another one with the same name, but it then bounced
with the message that there was no such user on the machine.  I
will resend the message if the poster can supply a working address.


What I want to address here is the response from Andrew Koenig
(ark@europa.att.com), which reads in part:

> That is, why bother with what looks like an array with no elements?
> What use is it?  The only answer I can think of is that you're intending
> to allocate `extra' memory and then subscript off the end of the array --
> and the standard definitely does not allow that technique, period.

Andrew, I'm afraid that *you* are definitely wrong, period.

The key word here is "allocate", meaning that the intention is to
do something like

	struct FM *p = malloc (sizeof (struct FM) + n);

In this situation the standard *does* allow a correctly declared
array element of the struct to be subscripted out of range, as long
as you stay within the malloc()ed area.  This has been discussed
at great length in comp.std.c not too long ago.  The only argument
that it might be illegal in this situation which was not countered
by reference to the standard amounted to saying that they must
have *intended* it to be illegal and didn't get the wording right.
-- 
Mark Brader	    "It's practically impossible to keep two separate databases
utzoo!sq!msb	     in step for any length of time.  That's true even when one
msb@sq.com	     of the `databases' is reality itself."   --Andrew Koenig

This article is in the public domain.
Newsgroups: comp.lang.c
From: chambles@whale.st.usm.edu (John William Chambless)
Subject: Re: People's Criticism of C (was Re: Macros)
Organization: University of Southern Mississippi
Date: Wed, 18 Nov 1992 00:19:03 GMT

In article <Bxu067.4L0@research.canon.oz.au> andy@research.canon.oz.au (Andy Newman) writes:
>
>Many of the posts slam C when users don't know how to use it safely.
>Is it C's fault that it is being used by inappropriate people in
>applications where another language may be more produective? I think not.
>

The very characteristics that make C so useful to many programmers are
the ones that make it so dangerous to the unwary. C will do whatever
you tell it to; if you tell it to do something stupid, well...

	who's to blame?


-- 
* Billy Chambless   University of Southern Mississippi, USA 
*   chambles@whale.st.usm.edu
*    
*   Programming exclusively in (--(C++))
Newsgroups: comp.lang.c
From: "gord armstrong" <gord.armstrong@canrem.com>
Subject: pvcs with brief
Reply-To: "gord armstrong" <gord.armstrong@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 16 Nov 92 12:14:57 EST


Can't seem to find a comp.version.control or comp.brief so I'll
dump my question here.

Anyone using PVCS 5.01 with Brief 3.1?  The PVCS macro that came
with Brief does not seem to work:  PVCS.CB   02-07-91

I set the macro up as per pg 210 of the Brief manual. If I load a
file: ie. b prgm.c  I get an error window. Further investigation
shows that the Brief macro is executing: get (prgm.c)  Why the
brackets? According to the PVCS manual, brackets are used for an
optional directory path for the retrieved workfile.

Is this macro for an older version of PVCS or am I doing something
wrong...or both?

Any help greatly appreciated.
--------------------------------------------------------------------
gord.armstrong@canrem.com
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.lang.c
From: freeman@gradient.cis.upenn.edu (Jon Freeman)
Newsgroups: comp.lang.c
Subject: Looking for public domain math software
Date: 23 Nov 92 15:15:56 GMT
Organization: University of Pennsylvania

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?

			Thanks,
			 Jon
			 (freeman@gradient.cis.upenn.edu)
Newsgroups: comp.lang.c
From: torstein@itekiris.kjemi.unit.no (torstein hansen)
Subject: What is meant by: double A[n,m]?
Organization: Dept. of Chem.Eng, Norwegian Inst. of Tech
Date: 18 Nov 92 12:51:46

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.

That is:
  double A[2,2];  
gave same result as 
  double A[2];

  A[0,1] = some_value;
gave same result as
  A[1,1] = some_value;
and 
  A[1] = some_value;

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?

By the way, the compiler I used was Turbo C++ ver. 3.1, just in case
this behaviour isn't standard.


Torstein Hansen
torstein@itekiris.kjemi.unit.no
--
Torstein Hansen
torstein@itekiris.kjemi.unit.no
Newsgroups: comp.lang.c
From: tim@unipalm.co.uk (Tim Goodwin)
Subject: Re: write an int?
Organization: Unipalm Ltd., 216 Cambridge Science Park, Cambridge CB4 4WA, UK
Date: Fri, 20 Nov 1992 13:07:40 GMT

map@ratt.rutgers.edu (O. C.) writes:

>I want to write an integer to a text file using the Unix system call
>write,

>write(file descriptor,buffer,size);

>but I can only seem to get it to work for strings and characters.

>What am I doing wrong?

Who knows?  Had you included a fuller description of the problem,
including a few lines of actual code that demonstrate it, it might be
possible to say.

If you've instantiated "file descriptor" with a valid file descriptor,
and "buffer" with the address of an int, and "size" with the sizeof an
int, and if the system call returned the same size you gave it, then
the int will eventually show up in the file/device/whatever that the
file descriptor refers to.

Note that: UNIX system calls are unlikely to exist on anything but a
UNIX machine; even on another UNIX machine, you will probably not be
able to read back the int; even if you know that you will never ever
want to do either of these, slinging binary data around makes
debugging hard, and is generally a Bad Thing.

What you probably want to do is something like this.

	#include <stdio.h>
	#include <stdlib.h>
	int main(void)
	{
		FILE *fd;
		int myint = 42;

		fd = fopen("somefile", "w");
		if (!fd) {
			perror("somefile");
			return(EXIT_FAILURE);
		}
		fprintf(fd, "%d\n", myint);
		fclose(fd);
		return(EXIT_SUCCESS);
	}

Note that I am ignoring the return values of fprintf() and fclose(),
which is rather sloppy.

Tim.
Newsgroups: comp.lang.c,comp.lang.c++
From: mat@mole-end.matawan.nj.us
Subject: Re: *** IMPORTANT DISCOVERY ***
Summary: Let's not get carried away, shall we ...
Organization: :
Date: Wed, 18 Nov 1992 06:40:45 GMT

In article <MJN.92Nov16010838@pseudo.uucp>, mjn@pseudo.uucp (Murray Nesbitt) writes:
> knaggs@cps.msu.edu (Scott A Knaggs) writes:
 
> > ...I turned around with my mouth full and kissed you. ...
> > You had a big smile on your face.
 
> ...  Some compilers, notably gcc, have extensions to the language that
> make this ... possible, but in the majority of implementations this
> code will result in undefined behavior.

I'm not fond of alt.tasteless either, but let's not get carried away ...
they're just not in the same league as gcc ...
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.lang.c,comp.software-eng