HDTenEightyP/NetNews huggingface dataset:
From: hjv@phil.ruu.nl (Hendrik Jan Veenstra)
Newsgroups: comp.lang.c
Subject: Re: Returning an array from a function -> How to?
Date: 11 Oct 92 13:19:01 GMT
Organization: Department of Philosophy, University of Utrecht, The Netherlands

msr52148@uxa.cso.uiuc.edu (Shepard) writes:

>I am fairly new to C, and I want to write a function that returns an array. 
>I would like to avoid passing in pointer to an empty array and modifying it
>that way.  I need one function that generates a table of integers dependent
>on an string/array of characters which is passed in as an argument.  I've 
>tried every arrangement of pointers and definitions I can think of, but nothing
>seems to work.  What I'm aiming for is something like this:

>int maketable(char *string)
>{
>   int table[xxx];
>   .
>   .
>   .
>   return (table);
>}

>main()
>{
>  int maintable[xxx];

>  maintable=maketable("TestString");
>}

>I'm sure this must be possible somehow, but I've spent the past two days 
>messing with pointers to this and that and nothing seems to work.  Any
>suggestions?  Thanks in advance!

The way you do it now is impossible - since 'table' is local to maketable(),
the value of table will not be valid after exiting the function. What's
the problem with the obvious 'pointer passing' method? I.e.:

int maketable( char *string, int *table )
{
   /* fill the table with whatever you want */
}

int main( int argc, char *argv[] )
{
    int table[TABLESIZE];
    char string[STRINGSIZE];

    /* ....... */
    maketable(string, table);
    /* ....... */
}


The other solution would be to dynamically allocate memory for table[] in
maketable() and return the pointer to this chunk of memory upon exiting
maketable(). Disadvantage (IMO) is that you have to think of 'free'ing
this chunk when you're done with it (e.g. when the program exits). 
The only reason -as far as I can see- to prefer this method over the one
described above, is in case you don't know the size of table[] in advance
and can only determine it while in the function maketable() (or if you
only need table[] for a relatively short while and it uses up lots of
memory - the malloc() method would then be safer I guess, cause you can free
the memory as soon as you don't need it anymore).


--
Hendrik Jan Veenstra  |  hjv@phil.ruu.nl  |   You look for your dreams in
Dept. of Philosophy   |                   |   heaven, but what the hell are
University of Utrecht |                   |   you supposed to do when they
The Netherlands       |                   |   come true...?
Newsgroups: comp.lang.c
From: Josef Moellers <mollers.pad@sni.de>
Subject: Re: How does free() work ?
Date: Wed, 14 Oct 1992 06:49:08 GMT
Organization: Siemens Nixdorf Info.Sys. AG, Paderborn, Germany

In <1992Oct12.182006.3996@darwin.ntu.edu.au> cjw@dme.nt.gov.au writes:

>I am just curious about the function of free(). If
>I have a linked list and I free the head of it ie.

>free(first_name) ;

>where name contains further linked lists called
>say, male_friends & female_friends, does free() then 
>de-allocate their memory as well ? Or is it necessary
>to do something like the following :

>free(first_name->first_male_friends) ;
>free(first_name->first_female_friends) ;
>free(first_name) ;

>This is not especially crucial on my machine, but will be 
>for the end users I suspect. 

Well, the right answer is: It depends.
"free(ptr)" should only be called with a pointer previously obtained by
calling "malloc(size)" and it will free exactly "size" bytes starting at
address "ptr". So, for every "malloc(size)" call, there should be a
corresponding "free(ptr)" call, freeing the allocated memory.
If Your whole family tree is stored in one chunk, allocated by one call
to "malloc()", then "free()" will free it all. But I assume that You
have malloc'ed every single member of the linked list, so You must free
every single member of the linked list.
If You have a bigger tree (not just two levels), the best thing is to
write a recursive function like:
	free_tree(node *ptr)
	{
		free_tree(all nodes lower than this);
		free(ptr);
	}

e.g. if Your node is something like

	typedef struct node {
		char name[10];
		struct node *girl;
		struct node *boy;
	} node;

free_tree() will look like:

	free_tree(node *ptr)
	{
		if (ptr != (node *) 0)
		{
			free_tree(ptr->girl);
			free_tree(ptr->boy);
			free(ptr);
		}

		return;
	}

If Your program will exit, You can skip the "cleaning up", as all the
malloc-ing is done in the virtual address space of the running process
and it's all freed by the system on an exit anyway.

-- 
| Josef Moellers		| c/o Siemens Nixdorf Informationssysteme AG  |
|  USA: mollers.pad@sni-usa.com	| Abt. STO-XS 113	   | Riemekestrasse   |
| !USA: mollers.pad@sni.de	| Phone: (+49) 5251 835124 | D-4790 Paderborn |
Xref: sparky comp.lang.c:14917 comp.software-eng:3752 comp.sys.mac.programmer:16879
From: erh0362@tesla.njit.edu (Elliotte Rusty Harold)
Newsgroups: comp.lang.c,comp.software-eng,comp.sys.mac.programmer
Subject: Re: Productivity of a C programmer ?
Date: 13 Oct 92 19:21:56 GMT
Organization: New Jersey Institute of Technology

> I can't see where you could ever reliably estimate anything on the Mac this
> way, since there's going to be some time spent looking up toolbox calls, etc.
> which will all effect how long it'll take - something straight-forward using
> little toolbox won't take long, and will get a high line count per day, whereas
> something requiring a lot more toolbox digging will be significantly lower...

	Even this is not necessarily true.  It applies if the programmer isn't 
too familiar with the Mac Toolbox and is quite familiar with the algorithms of
what the progrm actually does, but more commonly good Mac programmers can 
easily and quickly crank out (if not outright copy old code) toolbox 
initializations, event loops, and various menu-handling functions that comprise 
such a large part of the source lines in any Mac program while spending 
agonizing hours optimizing the functions that get most of the actual work done.
I think the key rite of passage for a Macintosh programmer is that point where 
the toolbox stops being an obstacle and starts being a quick way of writing a 
really impressive interface (by the standards of platforms other than the Mac 
at least :-) ).

--Elliotte
Newsgroups: comp.lang.c
From: bmehlman@trirex.com(Ben Mehlman)
Subject: Dynamically varying the # of args passed to a function (help!)
Reply-To: bmehlman@trirex.com
Organization: Trirex Systems Inc.
Date: Fri, 9 Oct 1992 22:12:04 GMT


Hello All.
What I am trying to do is the OPPOSITE of what is usually done:

I am trying to implement a remote procedure call kind of thing, where a  
name of a function, along with one or more blocks of data to be passed as  
arguments comes to me through a communications channel.  

I then find the ptr to that function in a table.  I then wish to call that  
function with my data items as arguments, ie, I want to push my stuff onto  
the stack, then call the function.  The function would take it's arguments  
and return as if it were called locally.

If I hard coded each function call into a big switch, then this problem  
would not exist.  I really don't want to do that.  I want all information  
to be kept in the table.

Is there any way to do this using some twisted manipulation of the vargs  
stuff etc??  I could accomplish this relatively easily by resorting to  
assembler, but that is not acceptable because I have to be portable.

Thanks for any advice, examples, etc!  Feel free to email or post!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
    \|/        Ben Mehlman                      Indigo..
   ^   ^       Trirex Systems Inc      
   #   #       bmehlman@trirex.com                   Indigoing..
     @
   \___/       >NeXTMail Welcome<                           Indigone.
Newsgroups: comp.lang.c
From: jonm@Ingres.COM (Go ahead... see if I care)
Subject: Re: gcc (WHERE TO FIND MSDOS GCC)
Summary: barancle.erc.clarkson.edu has the MSDOS version
News-Software: VAX/VMS VNEWS 1.4-b1  
Keywords: gcc djgpp msdos
Organization: ASK Computer Systems, Ingres Product Division
Date: 13 Oct 92 15:21:20 GMT

>>Where can I find gcc for both msdos and a sequent balance?
> 
>Someone posted this address recently for the MSDOS version:
> 
>	barancle.erc.clarkson.edu
>	in /pub/msdos/djgpp
> 

I can't seem to ftp onto this.  Would you have an internet ID?

			barancle.erc.clarkson.edu

Jon M
Xref: sparky comp.lang.c:14707 comp.os.msdos.programmer:9801 comp.programming:2843
From: ttk@ucscb.UCSC.EDU (William James Moyer)
Newsgroups: comp.lang.c,comp.os.msdos.programmer,comp.programming
Subject: Re: FAQ: Book for learning C.
Date: 9 Oct 1992 02:31:11 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: ucscb.ucsc.edu


>From: prangba@halcyon.com (Bruce Prang)
>Subject: FAQ: Book for learning C.
 
>I have a friend that is in the proceses of learning C. He is using an
>MS-DOS box to learn but he will be doing some of the programming on a
>Unix (AT&T SysV) box. He asked me for a recomandation but I didn't use a
>book in learning so I couldn't help him. How bout any of you fine folks?
>The book would ideally teach ANSI C with notes of perhaps how some of
>the MS-DOS compilers (MS, Borland, Zortech) differ. He's not looking for
>reference book, he has one of those. More of a real life kinda thing.
 
     I still sometimes refer to the text that was used in my 
"Introduction to C Programming" course a few years ago at DeAnza.  
It's called _C by Dissection_ and the authors are Al Kelley and 
Ira Pohl.  It's full of examples and explains things in multiple 
ways, and assumes no prior programming experience in the 
beginning.  In the latter parts it gets into dynamic allocation,
simple abstract data types (linked lists, etc), and some file io.
 
     It teaches C assuming ANSI C..  I recommended this book to my 
fiancee's father, and he later said the book was of great help.  
Unfortunately, it doesn't compare different software packages (ie, 
MS, Borland, Zortech), but in my experience TurboC's manuals do a 
good job of describing its extended features just fine..
 
                                                      -- TTK
Newsgroups: comp.lang.c
From: courtney@data.rain.com (Courtney Meissen)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: C expression evaluator
Date: 15 Oct 92 21:40:40 GMT
Article-I.D.: data.720
Organization: Microtek DSD, Hillsboro, OR


Does anyone know of a public domain or shareware C expression evaluator?
Ideally, it would be available as a callable set of routines in a 
Windows DLL.  But realistically, any old code will suffice (C code).

-- 
Courtney Meissen		   Microtek Development Systems Division
courtney@data.rain.com		   3300 NW 211th Terrace
uunet!intelhf!percy!data!courtney  Hillsboro, OR  97124  (503)645-7333x446
"There's a light at the end of the tunnel.. I hope it ain't no train."
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: |const| as an operator
Date: 14 Oct 92 23:53:35 GMT
Organization: negligable

"const" is NOT AN OPERATOR.

According to the grammer I have available (Ellis & Stroustroup,
The Annotated C++ Reverence Manual [ANSI Base Document]):

    declaration: decl-specifiers(opt) declarator-list(opt) ;

    decl-specifier: type-specifier |
                    storage-class-specifier |
		    "friend" |
		    "typedef" |
		    fct-specifier

    storage-class-specifier: "auto" | "register" | "static" | "extern"
			
    type-specifier: "const" | "volatile" |
		    simple-type-name |
		    class-specifier |
		    enum-specifier

(note: this is not a complete description, even of the parts shown)

in particular this implies that:

	int const i;
and
	const int i;

are the same thing, for that matter:

	static int i;
	int static i;

are also both syntactically legal.  By convention "static" tends
to come before the type involved (as far as I have encountered),
and we (at our company) have extended this convention to "const".

It suprised me to find (after recent discussions here & by e-mail)
that this was not syntactically limited to appearing in front
of the type.

This ambiguity is compounded when you start getting into the
more complicated combinations (I hope I get these right...):

	const char *p;		// changable pointer to constant data
				// (pointer to string constant)

	char const *p;		// same as above!

	char *const p;		// unchangable pointer to changeble data
				// (useful for memory mapped devices)

	volatile const char *const p;	
				// unchangeble pointer to non-writable data
				// that may be changed by external sources
				// (indicate that your memory mapped device
				// might change the value but that YOU
				// cannot)

	volatile char const * const p;	// same as above...

	char volitile const * const p;	// same as above...

	const char volatile * const p;	// same as above...

You can shuffle the "const" "volatile" and "char" that appear
before the "*" in any order without altering the meaning.  You 
can also toss in a storage class ("static" or "auto") just make 
life drive up the number of permutations and make life even more
interesting (and more difficult for the next programmer who
has to maintain your code....

Because "const" is NOT an operator you can NOT use parens
to alter the order of evaluation:

	char (const *) p;		// doesn't cut it

	
disclaimer: if I get any of this wrong, PLEASE somebody post
the correction.  for that matter if I've got it right could
somebody post a confirmation?

I think the standard should restrict the type-specifiers and
storage-class specifiers to before the object which they affect
(thus "char const *p;" would read as if the parens in my "doesn't
cut it" example worked -- as "char *const p;" currently works...)


		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Nobody has ever had a sexual fantasy about being tied
 to a bed and ravished by somebody dressed as a liberal."    -P.J. O'Rourke
From: zmahx11@ic.ac.uk (?/20000)
Newsgroups: comp.lang.c
Subject: Aribitrary precision maths
Date: 15 Oct 92 11:30:44 GMT
Organization: Imperial College Mathematics Department

Hi,
	I am looking for an arbitrary precision maths library which I
can use to play with numbers having 100+ digits. I wrote one myself but
I'm afraid that there is no way for me to check it other than by hand
(How do I multiply 100+ digit numbers on an HP32s and see *all* the
digits?).
I need it for some Number Theory work.
It goes without saying that i'd like a C library, but appreciated
extras include: ANSI C and portability.

Thanks,
	Arrigo
From: 1-9703@wwiv.cojones.com (Vladimir Taltos #1 @9703)
Newsgroups: comp.lang.c
Subject: Re: C and C++ books
Date: 8 Oct 92 22:26:20 GMT

Well, dunno if this is appropriate here, but here goes.  I am looking for
beginning C and C++ books, stuff like Master C, and such.  I went to the store
and most are $30 to $40.  I thought I'd see if any of you people wanted to seel
old copies or such before I lay out that kinda dough.  If you have some and are
interested, please e-mail me titles and what you want for them on WWIVNet
1@9703 please.  I not going to even try to wade through the post here for
reply's.  Sorry.  Bones?


                                                      Vlad.
From: masoodj@rigel.cs.pdx.edu (Javed Masood)
Newsgroups: comp.lang.c
Subject: How to read a string using FGETS function.
Date: 15 Oct 92 13:29:21 GMT
Article-I.D.: pdxgate.6222
Distribution: usa

Subject: How to read a string using fgets function.
Expires: 
Followup-To: 
Distribution: 
Organization: Portland State University, Portland, OR
Keywords: 
Apparently-To: masoodj@rigel.cs.pdx.edu
Status: R

Hi Netters, 
    I want to read a whole string by using fgets. I looked in help menu where
I found the definiton of fgets  "char *fgets(char *s, int n, FILE *stream)
but still couldn't find out how could I use this function to store whole string
in an array. Any help will be appreciated. Thx.  Javed Masood.
From: mark@laura.harvard.edu (Mark Rambacher)
Newsgroups: comp.lang.c
Subject: opendir, etc. for VMS
Date: 16 Oct 92 17:01:23 GMT
Article-I.D.: laura.MARK.92Oct16130123
Organization: Chemistry Dept., Harvard University

I am looking for dirent (opendir, readdir, ...) routines for VMS.
According to the FAQ, they DO exist.  My question is which host can I
ftp them from.  Archie has been no help.

While I am at it, does anyone know of a package which handles
keyed-access files under both VMS & Unix?  As far as I am aware, ndbm
has not been ported to VMS.  Any pointers to this or similar packages
would be greatly appreciated.

Thanks,

Mark Rambacher
mark@laura.harvard.edu
From: Jonathan Herr <herrj@valnet.UUCP>
Newsgroups: comp.lang.c
Subject: Re: TC++ 1.0 spawn() question.
Date: Wed, 14 Oct 92 08:59:13 EST
Reply-To: herrj@valnet.UUCP
Organization: WVCF, Vincennes, IN, USA
Disclaimer: Author responsible for contents

cp01395@dcsc.dla.mil (Duane L. Rezac) writes:

# From article <nhu1H8ug2a@atlantis.psu.edu>, by newton@wilbur.psu.edu (Cynthia
# > 
# > If I want to spawn a process using spawn, it only works if the file name
# > is in DOS's PATH variable. How can I explicitely give the location of a
# > file? e.g.
# > 
# > spawnvp(P_WAIT,"test.exe",NULL); <-works if the location is in PATH
# > spawnvp(P_WAIT,"C:\TEST\TEST.EXE",NULL) <-does not work, perror says
# > no such file or directory.
# > 
# > I'm using TC++ 1.0.
# > 
# > THANKS.
# I think that you also have to give the files's name in argv[0] -
# 
# spawnvp(P_WAIT,"C:\test\test.exe","c:\test\test.exe",NULL);
# 
# I had to do this for spawnl.
# 

How about this?

spawnvp(P_WAIT,"c:\\test\\test.exe",NULL);



Newsgroups: comp.lang.c
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: Strings and integer sizes
Date: Mon, 12 Oct 1992 13:40:28 GMT
Organization: D'Arcy Cain Consulting

wilson@rhombus.cs.jhu.edu (Dwight Wilson) writes:
>In article <1992Oct9.074449.12228@klaava.Helsinki.FI> wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
>>	char zoe[3] = "abc";
>Does anyone know what the rationale was for accepting this form?
>It's won't necessarily work on pre-ANSI compilers (in fact
>I expect it would break on most of them) so the excuse of 
>maintaining compatibility with old code doesn't apply.  It

There are plenty of legal ANSI programs that won't compile under pre-ANSI
compilers.  I believe the goal was to make legal (in the pre-ANSI sense)
code continue to compile under the new rules.  In other words, if the
the statement "char zoe[4] = "zoe";" used to be legal then it remains
legal.

>is likely to cause confusion and errors, just wait until someone
>tries to pass it to one of the str* functions.

Which is why this is best handled with:
    char zoe[] = "abc";
or if there is no need to modify zoe:
    const char *zoe = "abc";
and if you want a non-string character array:
    char zoe[3] = {'a', 'b', 'c'};

-- 
D'Arcy J.M. Cain (darcy@druid.com)  |
D'Arcy Cain Consulting              |   There's no government
Toronto, Ontario, Canada            |   like no government!
+1 416 424 2871          DoD#0082   |
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: Strings and integer sizes
Date: 9 Oct 92 10:01:38 GMT
Organization: AND Software BV Rotterdam

In article <1417@pacsoft.com> mike@pacsoft.com (Mike Stefanik) writes:
|In article <3568@carrousel.and.nl> jos@and.nl (Jos Horsmeier) writes:
|>So, I agree that a sequence of bytes '1', '2', '3', without a terminating
|>zero-valued byte does _not_ conform to the conceptual string type, but 
|>I disagree that char zoe[3] = "123"; would be an erroneous initializer.
|
|This *is* an erroneous initializer because you are initializing a three-
|character array with four characters. The side effects can be subtle; for
|example, consider the following program:
|
|    #include <stdio.h>
|    
|    char foo[3] = "foo";
|    char bar[3] = "bar";
|    
|    main()
|    {
|        printf("%s is %d characters\n", foo, strlen(foo));
|	return 0;
|    }
|
|On my system (UNIX, GCC compiler) this produces "foobar is 6 characters".
|On your box, it may cause a core dump, or (worst case) appear to act correctly
|even when memory is being inappropriately stomped upon.

Oh boy, we've started an `it is, 't isn't' discussion ... ;-)

Let me be a bit more precise: it is _not_ an erroneous initializer for
a character array. It is _not_ a valid initializer if you want to store
a string in this array, because the terminating '\0' byte is not stored.
Character arrays can be used for other things than just strings. 

I agree when you say that zoe[3]= "abc"; is an erroneous initializer
when you want to store a _string_ in the array, but otherwise this
is all perfectly legal. The ANSI-C standard even states this explicitely
in paragraph 3.5.7 Initialization.

kind regards,

Jos aka jos@and.nl
Newsgroups: comp.lang.c
From: alan@ulka.zso.dec.com (F. Alan Jones)
Subject: Re: Fast way of counting number of bits =1 in an int.
Keywords: bit operations
Reply-To: alan@ulka.zso.dec.com (F. Alan Jones)
Organization: Digital Equipment Corporation
Date: Wed, 14 Oct 1992 23:21:30 GMT


In case someone has not already posted this solution:

/*
        T_COUNT_BITS()
        Returns the number of set bits in a 32 bit unsigned int
*/
int t_count_bits(x)
unsigned x;
{
        x =    ((x & 0xaaaaaaaa) >>  1) + (x & 0x55555555);
        x =    ((x & 0xcccccccc) >>  2) + (x & 0x33333333);
        x =    ((x & 0xf0f0f0f0) >>  4) + (x & 0x0f0f0f0f);
        x =    ((x & 0xff00ff00) >>  8) + (x & 0x00ff00ff);
        return ((x & 0xffff0000) >> 16) + (x & 0x0000ffff);
}


Alan
From: roy%cybrspc@cs.umn.edu (Roy M. Silvernail)
Newsgroups: comp.lang.c
Subject: Incomplete structure declarations: only within structs?
Date: 7 Oct 92 23:32:13 GMT
Organization: Villa CyberSpace, Minneapolis, MN

I ran into a surprise last night.  I'm working on a little program that
has a data struct, and one function that takes a pointer to said struct
as a parameter.

I have a full set of prototypes in a header file, which happened to be
included before the struct was defined.  The compile bombed with "Type
mismatch in redeclaration of function", even though the declaration and
prototype were identical.  Moving the structure definition to before the
prototype cured the problem, but it leaves me confused as to why the
error occurred.

Recently, a thread covered the fact that "all pointers smell alike", so
it would seem that a prototype specifying a pointer to struct wouldn't
need any further information.  Shouldn't it be treated as an incomplete
declaration, as it would be if the pointer were included in another
structure?

I don't have a copy of K&R, and the manual (TC++ 1.01) is vague on this
point.  It says that I can pass a structure by value or pointer (or
reference, in C++), but says nothing explicit about whether precedence
is significant between proto and definition.  It merely shows prototype
examples, which match what I have declared.

Is this behavior to standard, or a compiler-specific bogon?  Either way,
just what _does_ the compiler think that pointer is when it evaluates
the prototype before the structure definition?
--
Roy M. Silvernail --  roy%cybrspc@cs.umn.edu - OR-  cybrspc!roy@cs.umn.edu
  perl -e '$x = 1/20; print "Just my \$$x! (adjusted for inflation)\n"'
          "Does that not fit in with your plans?"
                      -- Mr Wiggen, of Ironside and Malone (Monty Python)
Newsgroups: comp.lang.c