HDTenEightyP/NetNews huggingface dataset:
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: Arrays with variable dimensions?
Date: Thu, 31 Dec 1992 10:46:44 GMT
Organization: D'Arcy Cain Consulting

dirsolns@world.std.com (Bernard Farrell) writes:
>ah017@yfn.ysu.edu (John B. Lee) writes:
>: Is it possible to create an array that would change size according
>: to user input?
>float fl_arr[] = NULL;   /*  This is actually a float * -- no space  */

You didn't even try this did you?  This actually does assign space to an
array.  I don't know what your compiler does with the "= NULL" but assuming
it even accepts it (mine doesn't) it certainly doesn't do what you think it
does.  If you want a float * why didn't you just declare that:

float *fl_arr = NULL;

I would do the rest slightly different than your example but with the above
change your code should work.

>This allows the array to increase in size as required.  The
>alternative is to do a malloc(), instead of using realloc(),
>based on a value given at run-time.   Note that the above
>code works only when realloc() works as malloc() when the
>first parameter is NULL -- some implementations of realloc()
>do not have this behavior.

If you can count on an ANSI compiler you are fine but using a malloc first
is safer if you can't be sure.  Perhaps something like this at the start
of the code:

#ifndef	__STDC__
  if ((fl_arr = malloc(sizeof(*fl_arr) * ARRAY_INCR)) == NULL)
    print_horrible_error_and_exit();
  fl_max = ARRAY_INCR;
#endif

Of course if you are really paranoid about the __STDC__ constant you'll
just do this every time regardless.

-- 
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   |
Newsgroups: comp.lang.c
From: mckelvey@fafnir.com (James W. McKelvey)
Subject: Software - Practice and Experience
Reply-To: mckelvey@fafnir.com
Organization: Fafnir Software, Saugus, CA, USA
Date: Thu, 24 Dec 1992 02:45:34 GMT

Could someone please provide me with the address of the magazine "Software -  
Practice and Experience".  I desperately need an article with calendar  
algorithms from that journal.

Thanx, Jim McKelvey

mckelvey@fafnir.com
-- 
A man should not strive to eliminate his complexes, but to get in
accord with them; they are legitimately what directs his conduct
in the world. - Sigmund Freud
Jim McKelvey                      mckelvey@fafnir.com
Newsgroups: comp.lang.c
From: kamat@kailash (S M Kamat)
Subject: q
Organization: Indian Institute of Technology, Bombay
X-Newsreader: Tin 1.1 PL4
Date: Tue, 29 Dec 1992 08:38:16 GMT
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: C code Layout
Date: 29 Dec 92 23:06:42 GMT
Organization: negligable

In article <1992Dec23.165659.3298@mfltd.co.uk: nmp@mfltd.co.uk writes:
:
:In article <1992Dec23.153137.13423@fcom.cc.utah.edu>, swillden@news.ccutah.edu (Shawn Willden) writes:
:> hartman@ulogic.UUCP (Richard M. Hartman) writes:
:> 
:> [ Styles A and B deleted (you already know what they are) ]
:> 
:> : ... am I in the minority here by preferring style C:
:> : 
:> : 	keyword (condition) 
:> : 		{
:> : 		statement1;
:> : 		statement2;
:> : 		statement3;
:> : 		}
:> 
:> This thread is entirely too polite.  Don't you people know that when
:> coding styles are discussed massive *FLAMAGE* and LOTS OF SHOUTING IS
:> REQUIRED TO DO THE SUBJECT JUSTICE???????
:> 
:> In keeping with internet custom I would suggest to Mr. Hartman that he
:> GET A LIFE AND A REAL EDITOR LIKE EMACS AND STOP SCREWING AROUND WITH
:> VI FOR HELLS SAKE MAN DONT YOU KNOW THIS IS THE 90S???!?!?!?  YOUR
:> PROBABLY ONE OF THOSE PINKOCOMMIE WHITESPACELOVING FREAKS TO!!!!

Sorry, this thread is on coding style.  Editors is another
religious argument entirely.		:-)

Actually I prefer Brief -- but they don't have it on my 
UNIX system.  Vi is an OLD friend, and I can make it sing
and dance.  Emacs has too many Alt-Meta-Cokebottle wierdnesses
for me.

Have you tried VAX EDT in "nokeypad" mode?  Now there's
an editor!	;-)

(I hated the thing in "keypad" mode myself....)

:> Shawn Willden
:> swillden@icarus.weber.edu
:> 
:> P.S. I prefer style C myself

:-D

:Get a life? Get a real editor like EMACS? At the risk of getting off the
:subject, EMACS is poo, full of disgusting cryptic control sequences
:(what was it CNTRL-X CNTRL-S to save?) and vi is quite wonderful and sexy
:and fun and great and etc etc.
:
:And as for white space I think thats nice too.

I would say necessary!

:
:Oh yes. C layout.
:I like..
:
:    keyword( fruitbat )
:    {
:        ocelot(PINKOCOMMIE);
:        etc etc..
:    }

Oh well....




=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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....			|
Newsgroups: comp.lang.c
From: lebrun@ll.mit.edu (Steven F. LeBrun)
Subject: Re: assert
Organization: MIT Lincoln Laboratory, Lexington, MA
Date: Mon, 21 Dec 92 15:43:40 -0500


>	The first alternative (#include <stdio.h>) is forbidden by the C
>	Standard (standard headers may not #include other standard headers).
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I took a look at the ANSI C document (X3.159-1989) and could not find a
section that states that standard header files cannot include other
standard header files.  As a matter of fact, section 4.11.2 "Standard
Headers" states that header files included in any order and may be 
included more than once with the same effect as if they were included
only once.  [There is an exception pointed out in this section about
the <assert.h> header file.]

Since this section of the ANSI C document states that header files can 
be included more than once and in any order (with the possible exception
of <assert.h>) and does not explicitly state that standard headers may
not include other standard headers, that standard headers may include
other standard header files.  I would think that standard header files
including other standard header files is almost a necessity in order that 
standard header files may be include in any order and still keep the 
standard header files as simple as practical.

If there is a section in the ANSI C standard that explicitly, or 
implicitly, states that one standard header file can not include
another standard header file, I would like to know about it.  Please,
email the section number.
--

+--------------------------------------------------------------------------+
| Steven F. LeBrun             |      MIT Lincoln Laboratory, Group 91     |
|                              |        244 Wood Street, Room LI-136       |
| lebrun@ll.mit.edu (Internet) |          Lexington, MA 02173-9108         |
| lebruns@merlin    (internal) |  Phone:(617)-981-5742, FAX:(617)-981-0991 |
+--------------------------------------------------------------------------+
|"Hard as lightning, soft as candlelight;                                  |
|                    Dare you trust the Music of the Night?" - The Phantom |
+--------------------------------------------------------------------------+
Newsgroups: comp.lang.c
From: jblaine@garnet.acns.fsu.edu (Jeff Blaine)
Subject: Looking for simple curses help.
Organization: Florida State University
Date: Fri, 1 Jan 93 17:54:01 GMT

I've checked out the curses man pages and written a small very simple
program to do two window handling.  I need more help with how things
work with curses though.

If anyone has some decent small curses programs or sample code, I
would appreciate it if he/she could mail it to me so that I can get a
better grasp of curses before deciding to write something major.

I would go buy a good book on curses, but funds are tight as usual.
Thanks so much.
-- 
-------------------------------------------------------------------------------
J. Blaine			|	jblaine@garnet.acns.fsu.edu
3801 Mission Trace Blvd L-2	|	cblaine@gnu.ai.mit.edu
Tallahassee, FL 32313		| "I'm not GRUMPY, damnit.  What the hell is
Newsgroups: comp.lang.c
From: mark@ocsmd.ocs.com (Mark Wilson)
Subject: Re: show PCX
Organization: Online Computer Systems, Inc.
X-Newsreader: Tin 1.1 PL5
Date: Tue, 29 Dec 1992 12:13:16 GMT

(Oh, PS: please feel free to e-mail me if you'd like; I'll post
a summary of any responses, sources, etc. I receive...)

An another question (best answered via e-mail, I suppose):
is there another newsgroup which would be a better place to
enter this note?  Our site doesn't have access to all newsgroups,
but I'm willing to try... thanks!

--
-------------------------------------------------------------------------------
Mark Wilson, Online Computer Systems.  1-800-922-9204 or 1-301-601-2215
(Try email address mark@wilson.ocs.com....)
This file .disclaims everything signed with my .signature, I .mean it!
-------------------------------------------------------------------------------
Newsgroups: comp.lang.c
From: tt@sulla.jyu.fi (Tapani Tarvainen)
Subject: Re: DeskJet 500C and HP-UX
Originator: tt@sulla.math.jyu.fi
Organization: University of Jyvaskyla
Date: Tue, 29 Dec 1992 19:18:20 GMT

In article <TT.92Dec29124934@sulla.jyu.fi> tt@sulla.jyu.fi (Tapani
Tarvainen) writes stuff that doesn't belong here at all ...

I'm sorry about posting to wrong groups -- I have comp.lang.c and
comp.sys.hp next to each other in my .newsrc and my fingers must've
slipped (I'll punish them by biting my nails or something).
So, my apoligies and Happy New Year to everybody!

--
Tapani Tarvainen  (tt@math.jyu.fi, tarvainen@finjyu.bitnet)
Newsgroups: comp.lang.c
From: murtaza@ecf.toronto.edu (MURTAZA HASAN)
Subject: Turbo Vision
Summary: Help on Turbo Vision
Organization: University of Toronto, Engineering Computing Facility
Distribution: comp.lang.c
Date: Tue, 29 Dec 1992 20:28:38 GMT

	Could anyone tell me where to get some information on Turbo Vision, 
the OOP template by Borland, which comes with Turbo C++?  The source code would be nice, but just some simple programming information would suffice.


Newsgroups: comp.lang.c
From: alan@sal.wisc.edu (Alan Watson)
Subject: Re: speed?  double vs. float.  math.h??
Organization: Space Astronomy Lab, Madison WI
Date: Sat, 26 Dec 1992 17:44:03 GMT

In article <1hh801INNab1@agate.berkeley.edu> c60b-3hu@web-3c.berkeley.edu (Paul Hsu) writes:
>
>Trying to make the program run fast, I would like to have only float 
>variables, instead of doubles, in my program.  But in the standard math 
>library, all the functions take in arguments and return values in the type 
>double.  So, what should I do?

Your saving depends on your compiler and architecture.  I have only
noticed order 20% speed increases when moving from doubles to floats in
register-intensive code on RISC machines and VAXes, but on other machines
(without a FPU, perhaps, or using H_FLOATs on uVAXes :-) there may be
more of a problem.  I'd suggest benchmarking a test program to help you
decide if any effort is worthwhile.

However, if you are using standard mathematic functions extensively,
then your overhead will increase, because of those extra 7 digits or so
of precision which get calculated.  See if your machine has a
(non-standard) single precision library (sinf, cosf, etc.).  Or write
one yourself.  I have found that one can squeeze perhaps 30% from the
double routines by dropping to floats, using floating-point format
dependent but otherwise standard C.  Writing your own math library is a
very good educational experience for a numerical programmer -- it lets
you know all about those different kinds of errors.  (It actually is
fairly easy, once you get going -- writing a good double precision
library is a job for professional, though.)

Using casts will not help at all -- you compiler is already putting them
in implicitly, i.e., it is re-writing:

	#include <math.h>
	float x, y = 1.0;
	x = sin (y);

as:

	#include <math.h>
	float x, y = (float) 1.0;
	x = (float) sin ((double) y);

Is it worth all the effort to get an extra 30% from the code?  Only you
can decide.
Newsgroups: comp.lang.c
From: darcys@fraser.sfu.ca (Darcy Smith)
Subject: Re: Newbie Wants Advice on C-Programming
Organization: Simon Fraser University, Burnaby, B.C., Canada (sortof)
Date: Sun, 3 Jan 1993 19:00:02 GMT


From newsserver.sfu.ca!cs.ubc.ca!destroyer!gatech!swrinde!zaphod.mps.ohio-state.edu!cs.utexas.edu!uunet!pipex!bnr.co.uk!uknet!mcsun!sun4nl!and!jos Sun Jan  3 09:27:40 PST 1993
Article: 34226 of comp.lang.c
Xref: newsserver.sfu.ca comp.lang.c++:27833 comp.lang.c:34226
From: probreak@matt.ksu.ksu.edu (James Michael Chacon)
Newsgroups: comp.lang.c
Subject: Re: Methods to find all files' name of the directory in UNIX
Date: 24 Dec 1992 04:29:11 -0600
Organization: Kansas State University
NNTP-Posting-Host: matt.ksu.ksu.edu

wangbs@casd1.iie.ncku writes:


>   Hi, all:
>       How can I program to find all files' name of a directory in UNIX?
>   It is better having a example to show this.   HELP!!!
>   
>                Thanks for any response.

>                                        wangbs@casd1.iie.ncku.edu.tw

In the book Advanced Programming In The Unix Environment they give an 
example using opendir. This then returns you a pointer to a DIR structure.
You can run readdir on it until it returns null to get the name of each file
in the directory. Below is the example they gave.

James


-- Cut Here --

#include <sys/types.h>
#include <dirent.h>
#include <ourhdr.h>

int
main(int argc, char *argv[])
{
  DIR *dp;
  struct dirent *dirp;
  if (argc != 2)
    err_quit("a single argument (the directory name) is required");
  if ((dp = opendir(argv[1])) == NULL)
    err_sys("can't open %s", argv[1]);
  while ((dirp = readdir(dp)) != NULL)
    printf("%s\n", dirp->d_name);
  closedir(dp);
  exit(0);
}
Xref: sparky comp.lang.c:18987 comp.lang.c++:18510 comp.lang.fortran:4855 comp.os.os2.apps:9710
From: hamby@cs.utk.edu (Jeffrey Mark Hamby)
Newsgroups: comp.lang.c,comp.lang.c++,comp.lang.fortran,comp.os.os2.apps
Subject: 32-bit C/C++ & Fortran compilers question
Date: 29 Dec 1992 21:07:02 GMT
Organization: University of Tennessee, Knoxville - Department of Computer Science
Distribution: na
NNTP-Posting-Host: duncan.cs.utk.edu
Summary: seeking advice/comments on 32-bit C/C++ & Fortran compilers
Keywords: C/C++, Fortran, compiler
Originator: hamby@duncan.cs.utk.edu



I'm new to this newsgroup, so please excuse me if I'm asking in the wrong
place.  I'm looking for C/C++ & Fortran 32-bit compilers for a 486-based
pc.  The OS will probably be OS/2 but could possibly be a pc Unix.  I'd
like minimal (read that zero) problems with object file and run-time
compatibility, so I'm thinking same vendor for both compilers.  The 
purpose of the compilers is to do some number-crunching (bet you guessed
that).

From what I could find in ads for Lahey, Zortech, Borland, MS, Watcom, &
Microway, only Microway's NDP (Numeric Data Processing) compilers meet
all my specs.  Either another vendor offers only C & Fortran but no C++,
or another one offers no Fortran, or another one offers only 16-bit, etc..

If anyone would care to offer advice, suggestions, experiences, or other
comments on Microway's NDP C/C++ & Fortran 32-bit compilers for the i486
(or for the i386, if you've experience with that), I'd really appreciate
it.  Or if you know of some alternative I've missed, I'd appreciate
hearing about that, too.

Please post your replies to the group if you'd like others to benefit
from your comments as well, but if you do, please also send me email, as
I don't always get to read news on a timely basis.

Thanks a whole bunch in advance for all your help,

mark
hamby@cs.utk.edu
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: Function definition style
Date: 31 Dec 92 02:33:18 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <1992Dec30.223045.29467@news2.cis.umn.edu>, wright@staff (Mark Wright) writes:
>Is there any good reason not to use the following style for defining
>functions:
>
>type function_name( varname1, varname2, varname3 )
>
>type varname1;
>type varname2;
>type varname3;

Well, if your compiler can't deal with ANSI-style declarations, that's
about the only choice you have.  Also, if you're extremely concerned
about portability, and for some reason don't want to use the de-protoizer
utility that's freely available, you might also do this.

The bad things about this are:
  1. The compiler can't do parameter type-checking or auto-casting like it
     can with prototypes.
  2. This style of declarations has subtly different semantics from
     prototyped declarations.  A sloppy programmer might decide to
     play mix-n-match, which can lead to subtle, nasty bugs.
  3. Although it is still supported, presumably old-style declarations
     will someday be one with history.  All programs with old-style
     declarations will either have to be abandoned or proto-ized.


>I try to use the style in ansi k&r, but I notice that others are using this
>style and I assume they aren't all using pre-ansi compilers.

IMHO, one should be *very* careful in picking up coding habits from other
programmers.  Often a programmer will use a particular feature or style
out of laziness or ignorance of superior alternatives.

>My problem is that to use Brief's function listing command the end paren must
>be on the same line as the function name,

Oh, yeah.  Another reason programmers continue bad habits is to support
broken tools.  IMHO, you should complain to the vendor and/or seek an
alternative.  There's at least a few C-function utilities available in
the comp.sources.(unix|misc) archives.  I also have a simple function
lister I wrote myself, which is not dependant on where you put new lines
in your code (drop me a line if you're interested...)

If you still think pre-ANSI style declarations are better, just remember
every time you have a bug caused by mis-matched parameters or return type,
you should say

  "If I were using prototyes, the compiler would've caught this".

-- 
Caught an internal error--.brainrc restored
From: ceg@pnet51.orb.mn.org (Chris Galas)
Newsgroups: comp.lang.c
Subject: Directory search function needed
Date: 29 Dec 92 12:25:02 GMT
Organization: People-Net [pnet51], Minneapolis, MN.

Does anyone out there have a function that will search DOS directories
for a specific file (or a wildcard x*.* of files)?  Thanks!
 
+----------------------------------------------------------------------------+
| Christopher E. Galas                                 ceg@PNet51.Orb.MN.Org |
+----------------------------------------------------------------------------+
From: ta-psc10@cunixa.cc.columbia.edu (Po Shan Cheah)
Newsgroups: comp.lang.c
Subject: Re: fgets() sscanf() EOF confusion
Date: 30 Dec 92 16:59:02 GMT
Reply-To: ta-psc10@cunixa.cc.columbia.edu (Po Shan Cheah)
Organization: Columbia University

In article <1992Dec30.160832.3769@coe.montana.edu> sandy@cs.montana.edu (Sandy Pittendrigh) writes:
>while(!feof(inFile))
>  {
>  fgets(line,80,inFile);
>  sscanf(line,"%d %d %d %d", &x, &y, &z);
>  if(eof(inFile) /* But this doesn't work */
>   {
>   doSomething(x,y,z);
>   break;
>   }
>  else doSomething(x,y,z);
>  }
>
>Is this a resonable concept? 

Try doing it this way:

while (fgets(line,80,inFile) != NULL) {
  sscanf(line,"%d %d %d", &x, &y, &z);
  doSomething(x,y,z);
}

if (ferror(inFile)) {
 /* An error occurred. Do something about it. */
}

This is based on the fact that fgets() returns a NULL pointer if an
EOF or a read error occurs.
Po Shan Cheah
ta-psc10@columbia.edu
pc30@columbia.edu
pcheah@nyx.cs.du.edu
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Moving from Pascal to C, Help please!!!!!!
Date: 1 Jan 1993 01:59:41 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.15

In article <1992Dec31.211801.16730@i88.isc.com> katzung@i88.isc.com
(Brian Katzung) writes:
>#define	ARRAYLOWER	6
>#define	ARRAYUPPER	26
>int	_array[ARRAYUPPER - ARRAYLOWER + 1];
>#define	array	(&_array[-ARRAYLOWER])

As the FAQ warns (question 2.11), this technique is not strictly
kosher.  The effect of computing an out-of-bounds address is
undefined.  Most implementations will `do what you mean' here, but
there are no guarantees.

Note that the trick is fully portable if and only if the zero point
is contained within the array (i.e., ARRAYLOWER <= 0 < ARRAYUPPER),
because then &_array[-ARRAYLOWER] is within the array.  E.g., if
the lower bound is -3 and the upper bound is 1, then we have

	int	_array[1 - (-3) + 1];

or

	int	_array[5];

and -(-3) is 3, so we compute &_array[3], which is legal (3 < 5).
(In fact it works when ARRAYUPPER is 0 too, because given an array
N of T, we can always compute &array[N]; we are just not allowed to
try to *use* array[N].)

Incidentally, the name `_array' is reserved to the implementation when
external, so to make this right we also have to use some other name, or
make `_array' static or automatic.  (Technically, _array is safe if
and only if we give it `internal linkage' or `no linkage'.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
From: dwsmith@bilbo.encore.com (Dwight Smith)
Subject: "DEBUGGING C" (Sell me your copy - I'll pay shipping)
Organization: Encore Computer Corp.
Date: Thu, 31 Dec 1992 18:21:55 GMT
Keywords: debugging

Please sell me your copy of "Debugging C", by Robert Ward. I'll pay a good price for it plus shipping.

Thanks,
D. Smith

Newsgroups: comp.lang.c
From: gs@statlab.uni-heidelberg.de (G. Sawitzki)
Subject: Looking for April 1st C history
Followup-To: comp.lang.c
Organization: StatLab Heidelberg
Date: Mon, 21 Dec 92 16:07:07 GMT

On April 1st, a fake memo attibuted to Kernighan & Ritchie was circulated,
explaining why they invented C.
Some days later, there was a correction note pointing out a C bug in the
first one.
I am looking for copies of both.
    G. Sawitzki       <gs.statlab.uni-heidelberg.de>
Newsgroups: comp.lang.c
From: alec@stortek.com (Alec Sharp - x2955)
Subject: book publication
Reply-To: alec@stortek.com
Organization: Storage Technology Corp
Date: Mon, 28 Dec 1992 21:57:30 GMT

Please forgive the commercial nature of this post, but I thought that there
would be at least a few net users interested in it, and couldn't figure out a
way to disseminate the information in a way that would please everyone.

Title:		Software Quality and Productivity
Author:		Alec Sharp
Publisher:	Van Nostrand Reinhold
ISBN:		0-442-01218-7
Price:		$44.95

Synopsis:	This book is targeted at software developers, and attempts to
apply the philosophy of W. Edwards Deming to software development.  Throughout
the book the emphasis is on two things - reducing rework, and continually
improving the system.

However, adopting the philosphy of continual improvement means little unless
you worry about the details of what you will do and how you will do it. The
book contains both general ideas and specific suggestions of ways to improve
things.  Most people learn better from examples, so there are lots of examples.
All code examples are in C.

The book is not about doing it perfectly - I suspect perfection is impossible
because different projects have different complexities, people vary too much in
their needs, skill sets and personalities, and every solution contains the
seeds of the new set of problems.

Instead, a key theme of the book is to slowly but surely try to improve every
facet of the way that software is developed, always keeping in mind the goal of
reducing rework. This means trying new things and giving new ideas a chance,
then evaluating the results.


Alec

Alec_Sharp@stortek.com		Storage Tek, 2270 S. 88th Street
(303)-673-2955			Louisville, CO 80028-4286
"The real problem is not whether machines think, but whether men do."
Burrhus Skinner, 1969

Newsgroups: comp.lang.c