HDTenEightyP/NetNews huggingface dataset:
From: mjs@hubcap.clemson.edu (M. J. Saltzman)
Subject: Re: Strings and integer sizes
Organization: Clemson University, Clemson SC
Date: Wed, 7 Oct 1992 19:44:22 GMT

In article <3568@carrousel.and.nl> jos@and.nl (Jos Horsmeier) writes:
>[ someone asked about how strings are stored and ... ]
>
>In article <718167097snx@grendel.demon.co.uk>, jes@grendel.demon.co.uk
>(Jim Segrave) writes:
> 
>| What about:
>| 
>| char zoe[3] = "123";
>| 
>| neither b. nor c. applies here.
>
>|In article <1992Oct7.140844.816@newross.Princeton.EDU> blume@tyrolia.Princeton.EDU (Matthias Blume) replies:
>
>|Right, but this is *not* a string at all!  It's a character array together
>|with an initializer, which *looks* like a string.
>
>In article <1992Oct7.161704.5930@hubcap.clemson.edu> mjs@hubcap.clemson.edu (M. J. Saltzman) replies to that:
>
>|Furthermore, it is an erroneous initializer, since it is longer than 
>|its target array.
>
>Sorry, I have to disagree. In C, a string is no more and no less than

Oops, you are right.  K&R2 (and H&S3) both state that having more
initializers than array members is an error, but on closer
examination, I see that in the case of string literals, the ending
'\0' is not counted as part of the initializer if there isn't room for
it.  If it's not included, then I don't think the character array can
be said to be storing a "string".  On the other hand,

	char a[3] = "ABCD";

is indeed an invalid initializer.

>[...]
>Have a look at ANSI-C 3.5.7 Initialization:>
>`An array of character type may be initialized by a character string
>literal, optionally enclosed in braces. Successive characters of the
>character string literal (including the terminating null character
>if there is room or if the array is of unknown size) initialize the
>elements of the array.'

That cliches it...

>[...]
>Jos aka jos@and.nl

Sorry about that...

-- 
		Matthew Saltzman
		Clemson University Math Sciences
		mjs@clemson.edu
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.lang.c
Subject: Re: ANSI std vs. ISO standard
Date: 15 Oct 92 20:30:47 GMT

In article <1992Oct14.144238.6479@seas.gwu.edu>, dobrien@seas.gwu.edu (David O'Brien) writes:
> I wanted to get the ANSI C standard, so following the FAQ, I called ANSI.
> When I asked how to get the standard, they tell me that X3.159 has been
> replaced by ISO 9899 and this is what I really should get.  They act as
> though noone should want the ANSI standard now.  The cost of the ANSI
> standard is $50 and the cost of the ISO standard is $130.  They can't 
> tell me if the ISO standard even comes with the Rationale.  By chance
> does anyone know what the differences are in these two documents and
> whether or not the ISO document comes with the Rationale?  Which 
> should one order?

The differences between ANSI X3.159 and ISO 9899 are mostly editorial
(in particular, the section numbering is different) but ISO 9899 does
*not* include the rationale.  If you want the rationale, beg them to
sell you a copy of X3.159 if they have any left.  If not, complain
bitterly.  Especially about the fact that 9899 is nearly identical to
*half* of X3.159 and costs more than twice as much.  The committee
voted to replace X3.159 with 9899 so we didn't have to worry about
keeping the two in sync with each other, not so ANSI and ISO could
clean up by price gouging.  (Not that the price of X3.159 was all
that reasonable to start with....)
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
Domain: lawrence.jones@sdrc.com               IBMMAIL: USSDR7DR at IBMMAIL
You know how Einstein got bad grades as a kid?  Well MINE are even WORSE!
-- Calvin
Newsgroups: comp.lang.c
From: pal@regent.e-technik.tu-muenchen.dbp.de (Peter Loibl)
Subject: Re: How does free() work ?
Organization: Technical University of Munich, Germany
Date: Tue, 13 Oct 1992 14:52:12 GMT

wkaufman@us.oracle.com (William Kaufman) writes:

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

[stuff deleted]

>   Unfortunately, if there's some loop in the network, you could end up
>freeing a pointer twice, which is a Bad Thing (crashes on most system).
>In this case, you'll have to do some trick like:

>    - remember how many times you linked it; when you've deleted the
>      node (and decremented the count) enough times that the count is
>      zero, *really* free it.
>    - when you delete a node, walk through the whole network first and
>      remove every mention of it.

A freed pointer is not necessarily set to NULL! So the best way is to
set the pointer after free() to NULL and ask, if the pointer is NULL
before freeing it. You will get some major damages, if you try to
free a NULL-pointer.

The loops looks then like this:
(assuming, that first_male_friends and first_female_friends have the
type friend *)
>        void free_name(name *first_name)
>        {
>            if (first_name != (name *)NULL)
>            {
               if (first_name->first_male_friends != (friend *)NULL)
>                free_name(first_name->first_male_friends);
	       first_name->first_male_friends = (friend *)NULL;
               if (first_name->first_female_friends != (friend *)NULL)
>                free_name(first_name->first_female_friends);
	       first_name->first_female_friends = (friend *)NULL;
>              free((void *)first_name);
               first->name = (name *)NULL;
>            }
>        }

Hope this helps a little,
Peter Loibl
pal@regent.e-technik.tu-muenchen.de
From: djd@csg.cs.reading.ac.uk (David J Dawkins)
Newsgroups: comp.lang.c
Subject: Re: Is there is (pascal) WITH equivalent in C?
Date: 7 Oct 92 11:07:35 GMT
Organization: University of Reading


In article <scott.718402547@mcl> scott@mcl.ucsb.edu (Scott Bronson) writes:
> In <20992@plains.NoDak.edu> heilig@plains.NoDak.edu (Zachary Heilig) writes:
> 
> >try:
> >	a.next := a.next^.next;
> >	a.next^.next^.prev := a;
> >	      ^^who the hell thought up the ^. awkward operator anyway?
> 
> Niklaus Wirth, who do you think?  I like Pascal's "^." pointer indirection
> much better than C's "(*a).next".
                        ^^^^^^^^^

WHAT????!!!! 

"a->next" preferred over "(*a).next".

Surely.

-dave "Hold it - I sense a religious war"
-- 
djd@csg.cs.rdg.ac.uk
djd@csug.cs.rdg.ac.uk
davidd@integ.uucp
Newsgroups: comp.lang.c
From: williford@lub001.lamar.edu
Subject: PLEASE send the FAQ list to me........
Organization: Lamar University - Beaumont
Date: Sat, 10 Oct 1992 18:02:07 GMT
X-Posted-From: lub001.lamar.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

Could someone please send me the FAQ list for C.  

To keep me from getting tons of these, please do not send any after Sunday,
October 11.  Thanks.

T.I.A.  (Thanks In Advance)

*****************************************************************************
Rhett Williford
Systems Operator
ACM President-Lamar University, Beaumont, TX  USA
Internet: williford@lub001.lamar.edu
*****************************************************************************

Newsgroups: comp.lang.c
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Life, stderr, and everything (was Re: malloc() as a user...)
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 13 Oct 1992 12:37:38 GMT

dave@cs.arizona.edu (Dave Schaumann) writes:

>In article <15040@goanna.cs.rmit.oz.au>, ok@goanna (Richard A. O'Keefe) writes:
>>In article <Bvv6pH.Gzy@cs.psu.edu>, ytang@red.crayola.cs.psu.edu (Yuan-Ling Tang) writes:
>[...]
>>>     if ((p=(SOME_TYPE *)malloc(sizeof(SOME_TYPE))) == NULL) {
>>> 	printf("Malloc error.\n");
>>> 	exit(0);
>>>     }
>>
>>Bad.
>>(1) Standard output might be routed to a file.
>>    Use stderr, which is there precisely for you to write error messages.
>
>Perhaps so.  But particularly when I'm debugging, I want my error
>messages in *exact* sync with the rest of my program's output.
>Perhaps a better solution would be
>
>#ifdef DEBUGGING
>#define STDERR stdout
>#else
>#define STDERR stderr
>#endif
>
>and then use `fprintf( STDERR, "whatever..." )'

Better to just fflush(stdout), IMHO.

>>	if ((p = (SOME_TYPE *)malloc(sizeof *p)) == NULL) {
>>	    fprintf(stderr, "Unable to allocate enough memory.\n");
>>	    exit(EXIT_FAILURE);
>>	}
>
>I'm not particularly fond of either of the error messages presented
>here.  "Malloc error." is clearly lacking in specificity, and "Unable
>to allocate enough memory" is too vague on the details for me.  I'd
>greatly prefer a simple and accurate
>
>	FATAL ERROR: malloc() returns NULL
>
>Although I suppose that this is another thing that should probably be
>dealt with under the `#ifdef DEBUGGING' part, since I'm sure a non-
>programmer user would prefer something like
>
>	FATAL ERROR: insufficient memory to continue

If malloc fails, it may return an indication of the reason for failure
in errno, and if so then you use should use perror() to give that information
to the user. The message might be something informative like:
	Out of virtual memory
	Out of physical memory
	Per-process memory limit exceeded
	Per-user memory limit exceeded
	Memory allocation heap corrupted
	etc.

So here is a good malloc replacement:

----------------------------------------------------------------------

extern char *progname;	/* main() should initialize this to argv[0] */

void fatal_error(const char *message, int errno) {
    fflush(stdout);
    if (progname) {
        fprintf(stderr, "%s: ", progname);
    }
    if (errno) {
        perror(message);
    } else {
        fprintf(stderr, "%s.\n", message);
    }
    exit(EXIT_FAILURE);
}

void *safe_malloc(size_t size) {
    void *ptr;
    errno = 0;
    ptr = malloc(size);
    if (!ptr) {
	fatal_error("Unable to allocate enough memory", errno);
    }
    return ptr;
}

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: 873clifton@gw.wmich.edu
Newsgroups: comp.lang.c
Subject: Code to `pretty' print a balanced tree?
Date: 14 Oct 92 15:46:50 EST
Organization: Western Michigan University

Hello all:

I am looking for some example code to dump a balanced (AVL) tree to
stdout in a `pretty' or tree structured format, ala:

				(14)
			       /    \
			     (8)    (19)
			    /  \    /   \
			  (1) (11) (16) (21)

My reference is to a `node' or pointer based implementation of an AVL
tree with integer data items as in:

typedef enum bool { false, true } bool;
typedef enum bal { L, R, E } bal;
typedef struct AVL	{
	int data;
	bal bf;
	struct AVL *rchild;
	struct AVL *lchild;
} node;

I realize an routine to do this may/would require cursor control ala
curses--this is not a problem.

Thanks much,

/Doug
--
Douglas Clifton [99clifto@lab.cc.wmich.edu]
Newsgroups: comp.lang.c
From: sl313028@silver.ucs.indiana.edu (Jon Marcus Madison)
Subject: Re: ++i = i++ ?
Organization: Indiana University
Date: Fri, 16 Oct 1992 02:49:31 GMT

In article <356@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>In article <BvEK4w.MrL@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:
>>
>>In article <325@ulogic.UUCP>, hartman@ulogic.UUCP (Richard M. Hartman) writes:
>>
>>|> That's what he said.  Not very useful, but syntactically correct.
>>|> (with the possible exception of the missing ';', so you would
>>|> actually have to write:
>>|> 	for (i=0; i<Count, i++; )
>>|> for the compiler to buy it....
>>
>>The compiler buys (or *should* buy) the pre-increment version just fine.
>
>It wasn't pre- vs. post-increment that I was talking about,
>but the missing semicolon in the "for" statement in the original
>example.
>
i just did that yesterday, and I got an error.
(i was running turbo c++ 3.0  for in ANSI compilation mode.)
>
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Work away today, think about tomorrow.		|
>Never comes the day, for my love and me.	|	-Richard Hartman	
>I feel her gently sighing			|	hartman@uLogic.COM
>as the evening slips away....			|
>

-me
sl313028@silver.ucs.indiana.edu
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: No typedef
Date: 12 Oct 92 06:04:10 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <1992Oct11.192657.7275@waggen.twuug.com>, alpha@waggen (Joe Wright) writes:
>My C compiler does not support typedef.  I emulate typedef like this:
>
>#define nutyp struct nutyp
>	nutyp {
>		int ID;
>		char Name[32];
>	};
>
>	nutyp Person, *PersPtr;
>
>Is this 'as good as' a real typedef?  It seems to work here.

As long as you stick to structs, you should be OK.  However, this
doesn't have the general power of typedef.  For instance:

	typedef int vector[VSIZE] ;

	vector vlist[10] ;

There is simply no way to define a macro that acts the same as typedef
for "vector" above.  On the other hand, it's not unreasonable to
use the definition

	struct VECTOR {
	  int v[VSIZE] ;
	} ;

With this (virtually identical) declaration, you can use the
"define vector struct VECTOR" trick.  (Plus, with this definition,
you can assign vectors and get reasonable results).

-- 
Dave Schaumann			dave@cs.arizona.edu
Newsgroups: comp.lang.c
From: kestes@nswc-wo.nswc.navy.mil (Kent Estes)
Subject: wanted: _frealloc() for Microsoft C
Organization: Naval Surface Warfare Center
Date: Tue, 13 Oct 1992 17:20:57 GMT

Microsoft C's library doesn't seem to have a far realloc routine...
Does anyone have any source for one ?

replys via email appreciated,

       K. L. Estes (kestes@nswc-wo.navy.mil)

Newsgroups: comp.lang.c
From: wilson@rhombus.cs.jhu.edu (Dwight Wilson)
Subject: Re: Strings and integer sizes
Organization: The Johns Hopkins University CS Department
Date: Fri, 9 Oct 1992 12:53:47 GMT

In article <1992Oct9.074449.12228@klaava.Helsinki.FI> wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
>>:`An array of character type may be initialized by a character string
>>:literal, optionally enclosed in braces. Successive characters of the
>>:character string literal (including the terminating null character
>                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>:if there is room or if the array is of unknown size) initialize the
>  ^^^^^^^^^^^^^^^^
>>:elements of the array.'
>
>The initialization
>
>	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
is likely to cause confusion and errors, just wait until someone
tries to pass it to one of the str* functions.  

This initialization is illegal in C++ (though at least one of
the compilers I use doesn't even give a warning :-(), and IMHO
it was a mistake to allow this in C.  Any comments?

-Dwight
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: NULLing a pointer and INT 0x1c
Date: 8 Oct 92 22:02:24 GMT
Organization: negligable

In C++ you can pass by reference now (perhaps ANSI C took this too, but
I am not certain).

Old:
	func(int *p)
	{
	*p = 3;
	}


New:
	func(int &r)
	{
	r = 3;
	}


both behave identically, therefore:

	func(struct xxx &*p)
	{
	p = NULL;
	}

_would_ work the way you want it to.  Instead of taking a pointer
to a pointer and haveing to use the clumsy (*p)->field throughout
the function you can just use p->field as usual.  but you have the
added capability of changing p itself.  note: this can be rather
dangerous if you are used to treating params as local copies (the
old pass-by-value).


p.s.: if I got the syntax wrong for "reference to a pointer to struct xxx"
please someone correct w/ a followup.


		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Smoke me a kipper, I'll be back for breakfast!"
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: Strings and integer sizes
Date: 12 Oct 92 22:14:11 GMT
Organization: negligable

In article <1992Oct9.141754@is.morgan.com> berlin@is.morgan.com (Alexander Berlin) writes:
>|> >I have this in a central include file as:
>|> >	strncpyz(d,s,n) { strcpy(d,s,n); d[n] = '\0'; }
>|> 
>I have one more question to Mr.Hartman:
>
>    What is the purpose of having the third argument when calling strcpy
>    in your "central include file"?
>

Typo.  It's supposed to be "strncpy()".

The purpose is that strncpy() is not guarenteed to place a nul at the
end of the string fragment it copies and we wanted one.

And despite my reply to Lars, it's not a #define, it was upgraded
to an inline function in the include file:

inline char *strncpyz(char *s1, const char *s2, int n)
  { char *s; s = strncpy(s1, s2, n); s1[n] = '\0'; return s; }

less efficent than the #define (especially w/ that local "char *s")
but safer (I suppose....)



		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Practice random kindness and senseless acts of beauty.
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: Speeding up linked lists
Keywords: linked lists link pointer speed c efficiency
Date: 11 Oct 92 17:00:18 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <1992Oct11.035737.22361@ramsey.cs.laurentian.ca>, igor@ramsey (Igor Divjak) writes:
>I am about to undertake a rather large programming project using linked
>lists to store what might end up being several megs of data.
>
>I like the flexibility of linked lists, but the problem of speed concerns
>me.  
>
>I wonder if storing the locations of all the data elements in an array
>of pointers is faster than moving along a linked list.  Is it?

Well, it depends.  If you always access your data sequentially, you
probably won't notice any difference.  If you need to access your data
in a more random order, an array is of course going to be a big speed
win.

The problem with arrays, though, is that they don't work well if your
data structure needs to grow or shrink a lot.

>How else can one speed up linked list lookups?

Use a different data structure.  Hash tables, tries, binary search trees,
stacks and queues are all useful modifications on the basic linked-list
structure, and each has its own strengths and weaknesses.  Since it's
often difficult to know which will be best before you start working on
the program, it's best to write your code so that if you decide later that
you've chosen wrong, you can simply take out the code for one and plug
in the code for another.

This has the additional advantage that you can choose something easy to
implement to start, and then concentrate on getting the rest of the code
to work.  That way, you can use profile and other tools at your disposal
to see what areas of your code require more efficient implementation.

-- 
Dave Schaumann			dave@cs.arizona.edu
Newsgroups: comp.lang.c
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Strings and integer sizes
Organization: Computer Science, University of Melbourne, Australia
Date: Fri, 16 Oct 1992 05:57:09 GMT

hartman@ulogic.UUCP (Richard M. Hartman) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>hartman@ulogic.UUCP (Richard M. Hartman) writes:
>>
>>>inline char *strncpyz(char *s1, const char *s2, int n)
>>>  { char *s; s = strncpy(s1, s2, n); s1[n] = '\0'; return s; }
>>>
>>>less efficent than the #define (especially w/ that local "char *s")
>>>but safer (I suppose....)
>>
>>Inline functions are NOT less efficient than #define.
>>(Unless the inline function is too complicated for your dumb compiler to
>>actually inline.)
>
>It isn't the fact that it's an inline function, it's the fact
>that it now declars a local "char *s" that makes it more 
>efficient (doesn't it?), the previous definition was merely
>
>	#define strncpyz(d,s,n) { strncpy(d,s,n); s[n] = '\0'; }

Any decent compiler will optimize away the assignment to the local "char *s"
and then also optimize away "s" altogether, if the return value from
strncpyz() is not used.

If your compiler really is so dumb that it doesn't perform dead code
elimination, then get a better one.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c
From: st1n2@rosie.uh.edu (McCoy, Mark)
Subject: call graph generator
News-Software: VAX/VMS VNEWS 1.41    
Keywords:  graph tool
Organization: University of Houston
Date: Tue, 13 Oct 1992 03:56:00 GMT

I am faced with the following assignment as part of a team project
for a software engineering class:

-----------------------------------------------------------------------
The source code of a large software system is usually organized as a set
of files stored in a single directory.  Each file contains one or more
seperately compilable program units.  The way these units call one
another during execution provides an important clue about the working of
the software system.  Conceptually, this information can be represented
by a directed graph in which each node represents a subprogram, and 
each edge represents a possible function or procedure call.  Such a graph
is called a call graph.

In this project, the task is to produce a call-graph-generator that
accepts a directory name as input and constructs the call graph of the
software system contained in that directory.  It is assumed that all
programs (including the generator and its inputs) are written in C
under UNIX. 
-----------------------------------------------------------------------

I know that the above mentioned call grapher is a fairly common development
tool (I have seen plenty in advertisements but never in person).
Since this project is fairly open ended as far as required features, a good
starting point would be to see whats already been done and work from there.
So..Is there anything anywhere that fits the above description.  preferably
PD.
I am also in the process of hunting down an algorithm to solve the problem of
node placement on the graph.  Any help on either front would be much
appreciated.
Thanks in advance

Mark McCoy (st1n2@jetson.uh.edu)
From: mikef@dcs.ed.ac.uk (Mike Fourman)
Newsgroups: comp.lang.c
Subject: What should we do here?
Date: 16 Oct 92 12:50:23 GMT
Organization: Department of Computer Science, University of Edinburgh


I have just posted the following article to a local newsgroup for our
undergraduates. It is self-explanatory.
--------------------------------------------------------------------------

In the introductory practical, the newsgroup comp.lang.c was recommended.
This recommendation is withdrawn. The group has degenerated. It is now
a good example of the reasons for thinking hard before you post an article,
and thinking hard about the appropriate group to post to.

Many articles now deal with particular compilers or systems, rather than C
per se. Others are thinly disguised requests for the net do help with
practical exercises.

You SHOULD read the FAQ in comp.lang.c
Apart from that, its become a waste of time.
If you want real discussion of C try comp.std.c  -- but that gets a bit too
detailed for your present needs.

-- 
Prof. Michael P. Fourman                     email        mikef@dcs.ed.ac.uk
Dept. of Computer Science                    'PHONE (+44) (0)31-650 5198 (sec)
JCMB, King's Buildings, Mayfield Road,              (+44) (0)31-650 5197
Edinburgh EH9 3JZ, Scotland, UK                 FAX (+44) (0)31 667 7209
-------------------------------------------------------------------------------