HDTenEightyP/NetNews huggingface dataset:
From: Kari.Hurtta@Helsinki.FI (Kari E. Hurtta)
Newsgroups: comp.lang.c
Subject: Re: changing the contents of a file
Date: 7 Nov 92 20:41:47 GMT
Organization: Department of Computer Science, University of Helsinki, Finland

In article <15793@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) wrote:
> Several programming languages that support record-oriented transput have
> a REWRITE statement, or something like that.  COBOL, PL/I, and the VMS
> I/O library spring to mind.  In those languages/systems, the paradigm for
> modifying a record-oriented file is
> 	while not at end of file do begin
> 	    read a record;
> 	    if the record needs changing then begin
> 		change the record;
> 		rewrite the record;
> 	    end if;
> 	end while;
> C is NOT one of those languages, and the ANSI C stdio library is not one
> of those systems.  The fact that this code _needs_ ftell() and fseek()
> is how come we need a call to fseek() to switch modes.
> 
> Fact number 1:  if you want to switch from reading to writing, or from
> 		writing to reading, you must have a call to fseek().
> 		(Think of a FILE* as being in one of three modes:
> 		read, write, uncommitted.  fopen() and freopen() create
> 		FILE*s in uncommitted mode, fseek() and rewind() put
> 		them into uncommitted mode.  Then reading is allowed only
> 		when a FILE* is not in write mode, and writing is allowed
> 		only when a FILE* is not in read mode.)
> 
> Fact number 2:	the stdio library does not remember where the last "record"
> 		came from.  If you want to rewrite a record, you have to
> 		remember where it came from, and go back there. 

Fact number 3:	C's IO-model isn't record -based. One line 
		isn't record. File is series of characters.
		If you modify line, you better
		have write same number of character to line.
		or. Don't add one \n more to different place
		of line. Otherwise you create two line or destroys
		following line(*) -- depends have you written 
		replacement line shorter or longer than original.

(*) Well, what actually happens, depends underlay format of (text) file
    (in that OS).

- K E H
( Kari.Hurtta@Helsinki.FI,
  hurtta@cc.Helsinki.FI,
  hurtta@cs.Helsinki.FI,
  HURTTA@FINUH.BITNET
)
From: emmerik@utrcu1.civ.utwente.nl (Emmerik P.J.L. van)
Newsgroups: comp.lang.c
Subject: Anyone with experience porting from UNIX/X11 to MSDOS??
Date: 8 Nov 92 18:41:39 GMT
Organization: University of Twente

Anyone out there with experience in porting UNIX/X11 applications to
MSDOS?

We are investigating the possibility of porting a rather big UNIX/X11
application (about 25 Mb source) written in FORTRAN and C to MSDOS.
The reason we want to port to MSDOS is that a lot of people have a PC
that is adequate for our application, but the do not want to leave
MSDOS becouse of existing applications, or they do not want to learn
a new OS like for example UNIX.

What dit you do about the following problems:
- Limited file name lengths
  The development will continue on UNIX, so for sources i would not mind
  to convert file names automatically.
- Memory - UNIX has an "unlimited" virtual memory space for every proces
  Are there compilers or other methods to have an "unlimited" address
  space under MSDOS (or maybe Windows NT) ?
- Can linkers under MSDOS handle long routine names
  Our routines are unique within 9 characters.
- Can you combine C and FORTRAN code the same way you do under UNIX
  i.e. trailing underscore and extra parameters for stringlenths for
  FORTRAN routines
  Note: we could prevent the problem of combinig C and FORTRAN by converting
  our FORTRAN code to C using F2C.
- What dit you do about graphics, we currently use X11

Other things I would like to know are:
- What compilers and utilities dit you use
- Where can they be obtained (reps in The Netherlands or elsewhere in Europe)
_ What was the approximate cost

Are there any problems i dit not mention that i should think of?

Please E-mail to emmerik@utwente.nl

-- 
Pieter van Emmerik                    | Phone:  +31-74-464231
HDS info management                   | FAX:    +31-74-464110
P.O.box 23                            | E-mail: emmerik@utwente.nl
7550 AA  Hengelo, The Netherlands     |         hp4nl!utrcu1!emmerik
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: passing 2-dimensional arrays (was Someone help me with this)
Date: 8 Nov 1992 09:41:58 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

(Note: Please use descriptive subject lines.  `Help me with this' is
generally not very descriptive.)

In article <1992Nov6.235237.25636@sbcs.sunysb.edu>
rhorn@csws17.ic.sunysb.edu (Robert Horn) points out that declarations
of the form

	t1 f(t2 v[][])

(where t1 and t2 are types, f is a function name, and v is a variable
name) are illegal in C.  Further correct information can be found in
the comp.lang.c FAQ.

>... your example: char timetab[33][31] specifies an array from 0
>    to 30 of arrays 0 to 32 of characters.

This is backwards: the definition[%]

	char timetab[33][31];

declares timetab as an object of type `array 33 of array 31 of char'.
Each of the first `array's (each timetab[i] such that 0 <= i < 33) is
itself an <object, array 31 of char> and thus for each one, you can
write timetab[i][j], where j >= 0 and j < 31.
-----
% I say `definition' here to avoid the issue of formal parameter
  declarations (which are not definitions, and which act funny when
  told that a formal parameter has an array type).
-----

Again, see the FAQ for more detail.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Newsgroups: comp.lang.c
From: engber@ils.nwu.edu (Mike Engber)
Newsgroups: comp.lang.c
Subject: & of array - what does ANSI specify for resulting value?
Summary: unspecified or &foo[0]
Date: 12 Nov 92 17:43:05 GMT
Organization: The Institute for the Learning Sciences


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].

please cc via email if possible.

-ME
From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
Newsgroups: comp.lang.c
Subject: Re: The Correct Way To Write C if-Statements
Date: 6 Nov 92 16:15:29 GMT
Distribution: usa
Organization: Lawrence Livermore National Laboratory

In article <1dcfouINNc0r@crcnis1.unl.edu> holliday@cse.unl.edu (david holliday) writes:
>>		The Correct Way To Write C if-Statements
>>				by
>>			    Jim Minton
>
>I did a global search for the three-character sequence ":-)". Since the
>editor didn't report any, I can only presume that the author forgot to
>place after this character sequence after each paragraph of this post.

Well, the piece was certainly meant to be funny.  However, the author of
the work (Jim Minton) actually wrote this to establish a rule to be followed 
when writing C if-statements.  Minton eventually wants to establish a set of 
guidelines to be used locally for writing C code so that there is consistency 
in the appearance of the code, and will likely be doing more writing in the
near future.

Although there may be much disagreement about how to write if-statements,
or whether you should even have a guideline for such things, I thought it
likely there would be agreement that the post was funny, ergo I posted it.

mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948
Xref: sparky comp.lang.c:16047 comp.software-eng:4167 comp.sys.mac.programmer:18055
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c,comp.software-eng,comp.sys.mac.programmer
Subject: Re: Productivity of a C programmer ?
Date: 5 Nov 92 23:35:56 GMT
Followup-To: comp.lang.c
Organization: negligable

In article <Bx3KFK.7Er@cdsmn.mn.org> wells@cdsmn.mn.org (Rich Wells) writes:
>
>I use a very conservative means of measuring LOCs.  Blank lines do
>not count, lines with just a bracket do not count, and comments
>do not count.  When I count lines of code, I count just lines of
>real code.  In my case, this means about 1/4 of the lines in a
>source file count as LOCs.  Bummer.  I don't measure LOCs for
>productivity bragging rights, I do it to get a useful measure.
>
>As for comments, I don't count them as LOCs because the bulk of
>meaningful documentation is not in the code itself, but in
>separate documents where I can incorporate drawing to help explain

I have a program for counting lines of code that produces a summary
that includes the raw data:

	# lines of active code 
	# lines of code conditionally compiled out (see above)
	# lines of comments
	# blank lines
	# lines total

and some derived "scores" (my own opinons, not from any book
on software analysis or anything):

	code density = (nActive / nTotal) * 100;
	text tensity = 100.0 - ((nBlank/nTotal)*100)
	code/comment ratio = (nActive / (nActive+nComments)) * 100

(all calculations done in floating point).

Code density is what percentage of the file is "real" code.

Text density shows how readable the format is (no spaces 
between separate routines, major blocks of code, comments, etc gives 
a high density i.e. "wall of text" effect).

Code/comment ratio shows how well documented the code is.  A low
ratio you may have been spending more time explaining what you were
doing than doing it.  A high ratio may mean that it would be hard
for someone else to jump in and do maintenance.

Each of these values were based on my whim of what I thought might
be useful.  No flames on "that one is useless" please.  However, I
am certainly open to suggestions about other metrics to add to the
summary.		:)

I process #if/#else/#endif for literal values (1 or 0) and
(if I remember properly, it's been a while) single level symbolic
interpretations (#define DEBUG 1/#if DEBUG) but not yet for compound 
(#if 1 || DEBUG).

I consider conditionaly compiled out code important because you
DID spend time developing that debugging code, and it may be
useful in the future if you #if it back in.

Sorry, but I don't (currently) handle lines consisting of "{" or "}" alone
(with or without comments) as anything other than a line of code, but perhaps 
I should include that sort of thing.

		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I am just a figment of your imagination...
			...what does that say about *your* mental health?
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: Write a structure?
Date: 9 Nov 92 04:22:47 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <531@ulogic.UUCP>, hartman@ulogic.UUCP (Richard M. Hartman) writes:
> The problem is not that you cannot write pointer, but that it
> does you no good.

There are two problems.  One is that it doesn't do you any good to write
pointers (people keep telling me that it _is_ useful but nobody has sent
me as much as one line of code from a working program that does it). 
The other is that the compiler has enough information to _tell_ that it
won't do you any good, but because of the cast to void* is required to
forget that, shut up, and do it anyway.

> It is usually good form to write a routine that writes a structure
> that "knows" which fields are actually pointers that need to
> be dereferenced:

Agreed.  I even provided the students in question with sample code to do
this.  It helped that I had used Sun's XDR.  But that approach only works
when the data structure being written is a tree.  If you have N records
pointing to the same dynamically allocated string, you get N copies of the
string when you read them back.

> When you point out to a beginner what the problem is, and explain 
> something like what I have outlined here the problem goes away.  
> That what "beginners" are there for, to learn about the nasty stuff.

Gosh, you must deal with some wonderful beginners.  Tell them about a
mistake and they never make it again.  Re-read Donald Knuth's remark on
his bug-log for TeX.
From: hleaves@gems.vcu.edu
Newsgroups: comp.lang.c
Subject: Fortran to C conversion: Why bother?
Date: 9 Nov 92 13:16:00 -0400
Organization: Medical College of Virginia

I was wondering why anyone would bother using the f2c (or similar) program to
translate fortran code directly into C. All you end up with is C code that
exactly mimics the functionality of the original fortran code. Its not as if
the translating program rewrites your algorithms to use the parts of C that
make C really useful. Its just fortran code expressed in C. What's the point?
If you're going to write programs in fortran, use a fortran compiler. If you
want to use the features of C, learn C and use a C compiler. Using f2c doesnt
give you any of the advantages of designing and writing the original program in
C.

-Hugh
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: How to use 'return' in c?
Date: 6 Nov 92 14:47:15 GMT
Organization: University of Helsinki

With non-standard implementation there are no guarantees as to what any
particular return value of main or value passed to the exit function
means.  Traditionally, especially in Unix and systems mimicing Unix, the
code 0 has meant success, and small positive integers have been used to
show various error codes (the exact meaning of each code depending on
the particular program).  Other systems may have had different
conventions.  In summary, exit codes were non-portable.

The standard improves on this situation a) by specifying that 0 always
means success, and b) by introducing the macros EXIT_SUCCESS and
EXIT_FAILURE (in <stdlib.h>) with the obvious meaning.  Thus, using
standard C you can always rely on ``exit(EXIT_SUCCESS)'' to indicate
success to the operating system, and ``exit(EXIT_FAILURE)'' to indicate
failure.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
Newsgroups: comp.lang.c,comp.lang.c++
From: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: Re: Converting an int or a float into a string*???
Organization: VideOcart Inc.
X-Newsreader: Tin 1.1 PL3
Date: Fri, 13 Nov 1992 23:17:46 GMT

yhtao@magnus.acs.ohio-state.edu (Yu-Hui Tao) writes:
: Hi, netters:
: 
:    I have an array of numerical numbers of type either int or float. 
: What I want is to convert this array into of type char*. For example, 
: converting num[0]=1.02 into num[0]="1.02".   
: 
:    How do I do this in C and C++? Hope this is not too trival!
: 
   I would say impossible in the same array. you can convert from 
numeric to string though. the function gcvt() will do this.
syntax: char * gcvt(double value, int dig, char *buf)

value is the number to convert to a string
dig   is the number of significant digits
buf   is the destination char buffer
the return value is the pointer to the destination buffer

2 things: no error value is given back
          no overflow check is done on the dest buffer, so it is assumed
          that it is large enough to fit all of your significant digits
          into it.

also, if the number cannot be turned into the number of significant
digits you desire, it will automatically be put into scientific notation.

Bottom line, you need 2 arrays, or a structure where each element contains
the number and its textual version.

Dave fuller
dfuller@portal.hq.videocart.com



Newsgroups: comp.lang.c
From: esova@magnus.acs.ohio-state.edu (Edward R Sova)
Subject: Re: LINT
Keywords: LINT
Organization: The Ohio State University
Date: Thu, 5 Nov 1992 14:38:19 GMT

In article <27654@castle.ed.ac.uk> asm@festival.ed.ac.uk (M Smyth) writes:
>
>	Just a short post to ask if there are any PD versions af LINT
>and if so what FTP sites have them.
>	Thanks in advance.
>
>Martin.
>asm@festival.ed.ac.uk

Compuserve has a SHAREWARE lint.  CLT152.ZIP.  I just downloaded it, 
haven't checked it out yet.  The compressed file is 160K.

  ___
  \  \      Mr. Ed on rollerblades?  Nah, that's:
  _\  \      esova@magnus.acs.ohio-state.edu       Prodigy:CBGX09A
 \_____\       but his friends call him Ed,
 o o o o                    yeah that Ed Sova Kid, he answers to anything.
Xref: sparky comp.lang.c:16246 comp.lang.c++:16001 comp.lang.pascal:6446 comp.lang.misc:3559
From: pat@frumious.uucp (Patrick Smith)
Newsgroups: comp.lang.c,comp.lang.c++,comp.lang.pascal,comp.lang.misc
Subject: Re: Software design =/= Programming
Date: 10 Nov 92 00:52:05 GMT
Reply-To: uunet.ca!frumious!pat
Organization: None

reindorf@us-es.sel.de (Charles Reindorf) writes:
|OK, riddle me this. If I get you right, then if a statement A
|is provably undecidable,
|you assume that it is true.

No, you can only make this assumption for some statements.
For example, if A is of the form

   for all integers n, P(n) holds

where n is a proposition whenever P(n) is false, you can actually
prove that P(n) is false, then you can conclude that if A is
undecidable it must be true.  (Since if A were false, there would
be a counterexample, but then you could prove that P(n) was false
for that n, which proves ~A.)

-- 
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.lang.c
Subject: Re: About feof, ferror and return values (Was: Re: changing the contents of a file)
Date: 5 Nov 92 15:22:17 GMT

In article <1992Nov5.094701.9411@u.washington.edu>, bketcham@stein.u.washington.edu (Benjamin Ketcham) writes:
> What's the difference between an unconditional for loop and an unconditional
> while loop?

Well, there really isn't any such thing as an unconditional while loop
-- while loops always have a condition, although it can be a constant. 
for loops, on the other hand, allow the condition to be completely
omitted.  Infinite loops have traditionally been written in C as:

	for (;;) { ... }

but lately many people seem to prefer:

	while (1) { ... }

This is purely a style issue -- there is no good technical reason to
prefer one over the other.  (Originally, C compilers did very little
optimization and the first form actually generated better code.  I would
be very surprised if this was true of any contemporary compilers.)
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
He piqued my curiosity. -- Calvin
Newsgroups: comp.lang.c
From: faivre@cst02.segin.com (Denis Faivre)
Subject: Re: Bplus11 B-tree library
Keywords: b-tree bplus turboc
Reply-To: faivre%cst02.segin.com (Denis Faivre)
Organization: Segin, Groupe Axime
Date:  9 Nov 92 11:06:30 GMT

icsg0131@cs.montana.edu (Jeff) writes:


>Hello.  

>I have used the bplus package (v10 and v11) on a variety of compilers
>and never had a problem.  


I think the find_exact() function is buggy. I remember we had to recode
the loop inside to make it work correctly. I'm not sure, but I think
the problem occured when you have some records with the same key
and you try to find_exact anyone but the first of them.

Did somebody notice something like that ?

Denis.
-- 
Denis FAIVRE - AXIME                   When anything can go wrong, it w$*& !
Phone : +33 20.60.79.79
E-Mail : faivre@cst02.segin.com
From: travis@eecs.nwu.edu (Travis Marlatte)
Newsgroups: comp.lang.c
Subject: Re: Productivity of a C programmer ?
Date: 12 Nov 92 23:03:27 GMT
Organization: Rauland-Borg Corporation, Skokie IL

I don't understand the need to look at the source code to establish
productivity. Actually, I don't understand the need to establish
productivity at all. It definitely isn't needed to quote future
projects.

For example, when a hardware engineer creates estimates for a new
circuit he doesn't say, "I figure its going to have 1500 resistors,
1000 capacitors, 150 ICs... therefore based on ohms per hour I should
have this done in 14.6 man-days."

And when the circuit is complete, other engineers don't evaluate it based
on the number of compontents. They may evaluate its complexity, but not
directly its component count. Imagine a manager saying, "We're giving you
a raise. You deserve it. Last year you completed designs with 1M components.
Congratulations!"

When a programmer asks me to evaluate his work, I am not immediately
interested in the source code. I want to first know

	- how cleanly does it interact with the other parts of the system.
	- how well it interacts with the user (if any)
	- how does its processing time compare with ideal
	- how does its elapsed processing time fit into the system
	- how much executable space does it consume
	- how much memory does it require worst case
	- what trade-offs were made for code space against time

These are the external characteristics that can be quantified and compared.
I can compare the results of multiple programmers based on this kind
of information.

Then I want to look at the code. If it runs close to ideal in a minimal
amount of code space but the source code is unintelligible, it's garbage
unless there is a real need for the resulting performance. But if the
need is there, then speghetti code can be justified (sometimes).

If a programmer cannot provide the above information, then I don't think
the programmer actually engineered the code. It is more a result of hacking
together the first idea that had a chance - maybe with improvements done
after it was once working.

Lines of code and comments only add to readability. They mean nothing
in terms of productivity. I can take 6 months to engineer an algorithm
and make it readable in a day.

Why are you all so interested in productivity? If your jobs depend on it,
then maybe you should find a company that is more interested in real results
rather than fluff. Can you say 90210? I thought you could.

Travis "The source code fits on the disk so what do I care" Marlatte

-- 
Travis Marlatte
travis@eecs.nwu.edu
708-297-0055
Newsgroups: comp.lang.c
From: sophatsa@enuxhb.eas.asu.edu (Peraphon)
Subject: annotation of the ten-commandments
Organization: Arizona State University
Date: Sun, 8 Nov 1992 00:43:25 GMT

I used to have a copy of Henry Spencer's annotation of his ten-commandments,
but lost it.  Could someone tell me where to get it?  I have looked through
the ls-lR file and doc/programming directory at cs.toronto.edu, but only
found the original ten-commandments document.

	Thank you very much in advance.

					Regards,
					  Peraphon
From: rickr+@CMU.EDU (Richard Dale Romero)
Newsgroups: comp.lang.c
Subject: Printing out trees
Date: 8 Nov 92 19:21:44 GMT
Article-I.D.: andrew.gezTJc_00VQsAo9Vpl
Organization: Applications Software, Carnegie Mellon, Pittsburgh, PA

Does anyone have code for printing out arbitrary binary trees,
ie, not necessarily full, can have 0, 1 or 2 children?

Any sort of method or strategy would be nice, doesn't even
really have to be code.  I'm just stumped for a nice, efficient
way to do it--everything I've tried has been ugly.

-rick
Newsgroups: comp.lang.c