HDTenEightyP/NetNews huggingface dataset:
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: problem with foef()
Date: 12 Nov 92 19:41:22 GMT
Organization: University of Helsinki

U17868@uicvm.uic.edu has problems with the (paraphrased) code:

	while (!feof(f)) {
		read and process a record from f;
		if (!feof(f))
			read and process another record from f;
	}

You shouldn't use C's feof like Pascal's eof.  In Pascal, eof can
predict whether the next read will try to read past the end of the
file or not.  C's feof cannot do this, since, surprisingly enough, it
is not possible to know such things in advance except under special
conditions.  For example, how can feof know how much you will try to
read?  If there are, say, 2 unread bytes in a file, feof should not
return true if you will try to read only one or two bytes the next
time, but it should return true if you try to read more.  I'd like to
hear from people who can write such a predicting feof without breaking
the C I/O model.

The way you test for end-of-file in C is by trying to read something,
and then checking if it worked.  Every input function in the standard
library returns some special value (usually NULL or EOF) if the input
operation failed.  You should check the return value of the input
function every time and see if the read worked or not. 

For you particular problem the following outline should be pretty
good: 

	for (;;) {		/* "endless" loop, exit by break */
		if (fread(&record, sizeof(record), 1, f) != 1)
			break;
		process the record;
		if (fread(&record, sizeof(record), 1, f) != 1)
			break;
		process the second record;
	}

> file_pointer = fopen("activity.dat","rb");
> fseek(file_pointer,0,0);

You should check that fopen does not return NULL.  The fseek is
unnecessary, since the current file position is always at the
beginning of the file just after it has been opened.  Also, you should
use SEEK_SET instead of the last 0 (at least if you want to follow the
standard).

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
Newsgroups: comp.lang.c
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: Fortran to C conversion: Why bother?
Organization: Texas Instruments Inc
Date: Wed, 11 Nov 1992 17:27:47 GMT

In <20849@fritz.filenet.com> scotth@felix.filenet.com (Scott Hopson) writes:

>Keywords
>In article <1992Nov9.131601.167@gems.vcu.edu> hleaves@gems.vcu.edu writes:
>>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.

>Let's say your company was moving from a system like an IBM running MVS or a 
>DEC running VMS or some other similar beast to a Unix machine. You had lots of
>OLD code which was written in FORTRAN but your new environment was going
>strictly C and you knew there might be a need to maintain the OLD code, but you
>lost all your Hard Core Fortran Oldtimers.

>What would you decide to do?

>Many companies think seriously about converting their old code into new code,
>even if the functionality is the same. This is because they usually want the
>same functionality but with the opportunity to enhance old systems.

The problem with this decision is that the code resulting from
automatic translations is usually something less than maintainable, so
you would still have to either maintain the FORTRAN or reimplement in
maintainable C.  Converters are useful for those cases where you need
to get the first release of a product out the door when you are in a
new environment, but IMHO trying to maintain the output of a converter
after chucking the original code is rather like maintaining object
after chucking the source code.  It is somewhat more difficult than taking
the time to reimplement properly in the new language.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.lang.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Returned struct
Organization: SoftQuad Inc., Toronto, Canada
Date: Fri, 6 Nov 92 04:13:15 GMT


Stephen Lee (sl14@crux3.cit.cornell.edu) writes:
> : How can one make use of a struct returned by a function?  e.g.
> : 
> : struct complex complex_add(struct complex a, struct complex b);
> : 
> : I tried
> : 
> : struct complex z1, z2, z3;
> : 
> : z1.x = 0; z1.y = 3;
> : z2.x = 5; z2.y = 4;
> : 
> : z3 = complex_add(z1, z2);

This looks correct, but it is not a complete program.  The most likely
cause of the compiler's rejection of the code is that complex_add() was
actually defined *after* the code that called it, or in a separate file,
and no declaration of it was provided before the call in the same file
as the call.  If the lines quoted above actually occurred in the same
file in the order shown, and if struct complex actually contains members
named x and y whose type is arithmetic, then the problem must lie some-
where else in the program.

Dave Fuller (dfuller@portal.hq.videocart.com) responds:
 
> If indeed you want to use a return value, it should exist as a pointer
> to the structure ...  passing structures around is not the right way to
> deal with them, you need to pass them as pointers. Although some compilers
> allow passing of structures, lets assume it will end up on one that doesn't
> do this.

This reply of Dave's seems to have passed through some sort of time and
causality warp.  Stephen's question uses function prototype syntax, which
was introduced into C at the time of the ANSI standardization in the late
1980s.  Dave's article plainly shows by its content that it was written
much earlier, in the 1970s or early 1980s.  Yet it shows up today, in 1992,
*as* *a* *followup* to Stephen's question.  How on Earth is this possible?
Followups to rec.arts.sf.misc. :-)


H'rm.
The point is that, as the FAQ says (you have read it, Dave?), the passing
and assigning of structs has been part of C for something like 14 years
now, and most people now consider it reasonable to assume that they'll
never again see a compiler that doesn't support it.  The earliest C
compilers didn't support "unsigned short" or "unsigned long" either --
should we avoid those data types?  No; that'd be silly today.

If one is going to criticize Stephen's code for non-portability to older
implementations, then the one thing that must be seriously mentioned is
the use of function prototypes.  There are still quite a few compilers out
there that are over 5 years old and which will throw syntax error fits
when they see

    struct complex complex_add(struct complex a, struct complex b);

If the compiler's diagnostic had related to syntax rather than being
"illegal structure operation", and if the compiler wasn't mentioned as
being related to a C++ implementation, I would suspect that that was what
was going on here.  As it is, I can't say what is wrong; I can only say
what is right.
-- 
Mark Brader			"Nicely self-consistent. (Pay no attention to
SoftQuad Inc., Toronto		 that D-floating number behind the curtain!)"
utzoo!sq!msb, msb@sq.com			-- Chris Torek, on pasta

This article is in the public domain.
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: Finding length of file?
Date: 9 Nov 92 17:26:21 GMT
Organization: University of Helsinki

ceblair@ux1.cso.uiuc.edu (Charles Blair) writes:
>  Sorry if this is an FAQ, I couldn't find it in any of the current 
>postings.

It is.  Question 16.7.  If you can't find the FAQ in the newsgroup,
try checking the group news.answers, and if that fails too, ftp to
pit-manager.mit.edu, or send mail with the work "help" in the subject
to mail-server@pit-manager.mit.edu.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
Newsgroups: comp.lang.c
From: gay@selkirk.sfu.ca (Ian D. Gay)
Subject: Re: Reasons for using C vs. Fortran or vice/versa
Organization: Simon Fraser University, Burnaby, B.C., Canada
Distribution: usa
Date: Fri, 13 Nov 1992 00:23:25 GMT

rons@hardy.u.washington.edu (Ronald Schoenberg) writes:

>  Fortran arrays are column echelon for a
>reason, and C arrays are row echelon slowing down matrix operations
>relative to Fortran.     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Maybe I'm missing something, but I don't see why this should be so. 
Could you explain more fully?


>Ron Schoenberg
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.lang.c
Subject: Re: Returned struct
Date: 6 Nov 92 15:44:13 GMT

In article <Bx9pJE.Et4@portal.hq.videocart.com>, dfuller@portal.hq.videocart.com (Dave Fuller) writes:
> sl14@crux3.cit.cornell.edu (Stephen Lee) writes:
> : How can one make use of a struct returned by a function?  e.g.
> 
>   If indded you want to use a return value, it should exist as a pointer
> to the structure (which is either static or malloc'd, both are messy)
> secondly, passing structures around is not the right way to deal
> with them, you need to pass them as pointers. Although some compilers
> allow passing of structures, lets assume it will end up on one that 
> doesn't do this.

Structure assignment, structure arguments, and structure return values
were added to C in 1978, very shortly after K&R was published.  K&R
even mentions that it is expected that those operations would be added
in the future.  Any compiler you run across today that doesn't support
them is apt to be either so new and incomplete and it isn't likely to
be usable, or so old and venerable that it should be allowed to rest
in peace.  In the example Stephen gave (complex arithmetic), using
struct arguments and return values is exactly the right thing to do
since it allows you to write expressions like:

	d = cmp_sqrt(cmp_add(cmp_mult(a, a), cmp_mult(b, b)));

Granted, that's not as clear as you could do with C++:

	d = sqrt(a * a + b * b);

But it's a lot clearer than the mess you'd end up with if you only
used pointers and had to use explicit temporaries with lots of copying
between them.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
Years from now when I'm successful and happy, ...and he's in
prison... I hope I'm not too mature to gloat. -- Calvin
Newsgroups: comp.lang.c
Subject: Simple editor w/source wanted
From: jblst5@icarus.lis.pitt.edu (Jan B Larsen)
Date: 8 Nov 92 01:07:37 GMT
Reply-To: jblst5@icarus.lis.pitt.edu
Organization: University of Pittsburgh

I'm making a SMTP (simple mail transfer protocol) as a project for my
protocols/interfacing class at the University of Pittsburgh. This is a 
simple program for sending/receiving mail between two PC's. 
I'm looking for a very simple editor (the source code) which I will use in
my program. I only need to be able to use cursor keys, delete lines, delete
a characher and so on.

Is there a such editor out there?
BTW, I'm doing this in Turbo-C.

Thanks in advance.

Jan B. Larsen
MST student
Univ of Pitt
From: cbarber@bbn.com (Chris Barber)
Newsgroups: comp.lang.c
Subject: Re: To Recurse or NOT to recurse?
Date: 9 Nov 92 17:25:00 GMT
Organization: BBN Systems and Technology, Inc.

In article <1992Nov6.185136.8055@netcom.com> sjs@netcom.com 
(Stephen Schow) writes:
>What is better to do when traversing a linked list..... SHould I use recursion
>to search down through the list for the last node, or should I use a while
>loop?  What or the pro's and con's of each?

Recursion should usually be avoided in C for reasons of efficiency.  A
recursive linked-list traversal will require much greater overhead both for
CPU cycles (because of the instructions needed to make function calls) and
storage space (because of the use of the stack) than a while-loop traversal.
However, recursion can be appropriate if it greatly simplifies the code and
will not need to recurse very many levels, thus minimizing the cost of the
overhead.

This advice does not apply to code written in Lisp and other languages that
optimize tail-recursion.

-- 
Christopher Barber
(cbarber@bbn.com)
Newsgroups: comp.lang.c
From: ttobler@unislc.uucp (Trent Tobler)
Subject: Re: Binary Representation
X-Newsreader: Tin 1.1 PL5
Organization: Unisys Corporation SLC
Date: Thu, 5 Nov 1992 22:27:42 GMT

Ray Mitchell (mitch@nosc.mil) wrote:
: 
: It seems that since C has bitwise operators and its treatment of pointers
: is so close to the underlying hardware, there should be a way of representing
: constants in binary in addition to decimal, hex, and octal.  Does anyone
: know why this was not done?  Maybe I'm the only one who sees any value in
: it.  (Please don't tell me to use assembly if I want binary).  I've
: contemplated some macro way of implementing a binary representation but
: have not come up with anything reasonable.  Any ideas?

I can think of three ways:

#define BIN4(a,b,c,d)	((a<<3)|(b<<2)|(c<<1)|(d))
#define BIN8(a,b,c,d,e,f,g,h) ((BIN4(a,b,c,d)<<4)|(BIN4(e,f,g,h)))
#define BIN16(a,b,c,d,e,f,g,h) ((BIN4(a,b,c,d)<<4)|(BIN4(e,f,g,h)))
 /* you get the idea */

#define BINARY(dec)  ((dec%10)|((dec%100)/10)|((dec%1000)/100)\
		((dec%10000)/1000)|((dec%100000)/10000)|((dec%1000000)/100000)\
		/* you get the idea */ )
	/* has the problem of only being able to do 10 digits */
	/* also could make a hybrid between this one and the first one and */
	/* get more */


/* ANSI C */
#define BINARY(binary)	(strtol( #binary, (char **) 0, 2))
/* K&R C */
#define BINARY(binary)  (strtol( "binary", (char **) 0, 2))


Probably the reason for not including binary in the C language is that
binary tends to be long and bulky... and it is trivial to convert binary
to hex or octal in ones head.

--
  Trent Tobler - ttobler@unislc.slc.unisys.com
From: wenner@einstein.eds.com (Rich Wenner)
Newsgroups: comp.lang.c
Subject: Re: How to use 'return' in c?
Date: 5 Nov 92 15:00:22 GMT
Organization: Electronic Data Systems

In article <1992Nov4.231347.26999@u.washington.edu> chuckb@stein.u.washington.edu (Charles Bass) writes:
:After several people wrote me on the use of EXIT_SUCCESS and
:EXIT_FAILURE  and their inability to locate those files on their
:systems I checked K&R 2ndEd for the definitive answer...

Since when is K&R2 the Standard?

:" void exit(int status)
:... How status is returned to the environment is
:implementation-dependent, but zero is taken as successful
:termination.  The values EXIT_SUCCESS and EXIT_FAILURE may also
:be used."                                              ^^^
:
:Because the word *may* is used I must assume that you either get
:it or you don't depending on your compiler/OS.

Don't assume.  RTFS, which simply states that these macros are defined in
stdlib.h.  See section 4.10.

-- 
Rich Wenner              | Subject and verb always has to agree.
wenner@csid.gmeds.com    | Consult a dictionary frequently to avoid mispelling.
                         | Hopefully, you will use words correctly,
#include <stddisclaim.h> |            irregardless of how others use them.
Newsgroups: comp.lang.c
From: stuart@cosc.canterbury.ac.nz (Stuart Ralston)
Subject: SVGA drivers
Organization: University of Canterbury, Christchurch, NZ.
Date: Wed, 11 Nov 1992 00:44:51 GMT

Looking for the SVGABG40 drivers for Turbo C on a 286-16Mhz.  I heard
they're on the Simtel20 mirrors -- anybody got full address for this 
place?

\||||||/
/ o  o \	   ___  ____  stuart@cosc.canterbury.ac.nz
\ /  \ /	  /__    /   /  /	 
 (    ) 	 ___/   /   /__/     
  \__/
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.c
Subject: meanings of "void" keyword
Date: 07 Nov 92 00:12:30 GMT

: From: torek@horse.ee.lbl.gov (Chris Torek)
: Newsgroups: comp.lang.c
: [...]  `void' has two meanings in ANSI C:
:         - A void value is a value from the empty set. [...]
:         - A `pointer to (optionally qualified) void', or `void *', is
:           a `generic pointer' type [...]

Um.  I thought void had three meanings in ANSI C.  The above two, and 

         - A void prototype (eg:   void f(void);         )
           is an explicit declaration that f takes no arguments,
           introduced to a-void the ambiguity with the K&R
           meaning of an empty argument list.

In fact, these three uses are essentially independent.   The fact that
(void*) and (void) are both in the type notation and the third is not
make the two seem reasonable and related, but a "better" alternative
would have been to render the three cases:

          (void)
          (any*)
          void f(empty);

... because the pointer case isn't really related to the "value drawn
from the empty set" case.  But by that time in the standards process,
introduction of new keywords was something greatly to be avoided, so
the "void" keyword was triply overloaded instead of introducing two
more.

( I'd welcome comment from somebody who actually was part of the
  standards process for C... the above rumor is second or third
  hand. )

( Uh, mind you, the "void prototype" third usage isn't a rumor...
  I mean that the motivation for the triple overloading of void
  is a rumor that I have heard... )

BTW: the "any" keyword would have been useful in argument lists
and other places, apart from its use to coin the generic pointer.

         void f(int, any, any);

could be used instead of

         void f(int, ...);

to nail down the argument number, but leave the types generic.
(generic by-value argument passing opens up a whole new can of worms,
of course, but I'm sure the notion could be made to work in C.)
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.lang.c
From: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: Think this will fly ??
Organization: VideOcart Inc.
X-Newsreader: Tin 1.1 PL3
Date: Tue, 10 Nov 1992 19:37:08 GMT

 
Question:
 
  I don't know if this has been attempted before, but, would it be 
possible to label questions and answers for code with the level of
the person posting it ? 
 
It would be nice if we would know if the answer should just be an idea
for an algorithm, a very basic code outline, actual code, or code
that also includes an explanation. 
 
I like to answer alot of posts, and consequently, don't always give
every single bit of information about my reply. My assumption usually
goes something like this:  The code works, is easy to figure out, and
can be modified if needed. This is also assuming that the person asking
for the code can FULLY understand any change that is possible.
 
If i knew the level (novice, intermediate, advanced) i could respond
more correctly. I would also label the response with the level it was
written at. This way a novice would know that an advanced posting 
isn't the whole answer and wouldn't get stuck assuming it would work
in all cases as it was posted.
 
what do you think ??
 
Dave Fuller
dfuller@portal.hq.videocart.com
From: Scott.Pitcher@f395.n634.z3.fidonet.org (Scott Pitcher)
Newsgroups: comp.lang.c
Subject: Re: How to print an integer as binary?
Date: Wed, 11 Nov 1992 06:40:00 +1100

 TO> Assuming that:- 
 TO> 
 TO> int i = 203;
 TO> 
 TO> How do I display 'i' as 11001011?

#include <stdio.h>
#include <values.h>

void main()
{
        int i, j;

        printf("\nEnter 'i' : ");
        scanf("%d", &i);
        for(j = 0; j < 16; i <<= 1, ++j)
                printf("%c", (i & MAXINT + 1) ? '1' : '0');
        printf("\n%u", MAXINT + 1);

}

This will print with leading zeros and it assumes that the integer is
16 bits wide, but it is simple and it works. What more could you want?

Scott.

P.S. If you were using FORTH instead of C, a simple "2 BASE" would
allow you to print in Binary with out any hassles, and no leading
zeros.
 
 * Origin: Starbase Alpha On the Edge of the Universe! (3:634/395.0)
Newsgroups: comp.lang.c
From: lott@bogner.informatik.uni-kl.de (Christopher Lott AGSE)
Subject: Re: Productivity of a C programmer ?
Organization: Universitaet Kaiserslautern FB Informatik
Date: Fri, 6 Nov 1992 11:21:37 GMT

In article <560@ulogic.UUCP> hartman@ulogic.UUCP (Richard M. Hartman) writes:
>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

Speaking as a person who is trying to work on research that involves
using software metrics (NOT defining new ones), I find this statement
to be the archtype of statements that describe how metrics are misapplied.

You developed these metrics with some goal in mind.  I know you did,
else you wouldn't have developed them.  Make the goal explicit.  Write
it down.  Decide what you're trying to achieve (your goal).

Then decide what questions you're trying to answer with your metrics.
You're trying to answer more than just "how large is the code," clearly.
Why do I say "clearly?"  Because if you just want size, use wc.  That
gives you an exact indication of size.

Oh ho, so this isn't the size you wanted?  Wait.  That means you know
what you want and why you want it.  Be a little more methodical and then
you won't have to say "well I pulled these out of my hat and I don't know
what good they are." 

Summary: If you don't know what a metric is good for, it's useless.

chris...
p.s. Read this:
@article{basili88a,
        author = "Victor R. Basili and H. Dieter Rombach",
        title  = "{T}he {TAME} {P}roject: {T}owards
                {I}mprovement--{O}riented {S}oftware {E}nvironments",
        journal = IEEE Transactions on Software Engineering,
        year    = "1988",
        volume  = "SE-14",
        number  = "6",
        month   = jun,
        pages   = "758--773",
        keywords = {TAME, GQM}
}
-- 
Christopher Lott    lott@informatik.uni-kl.de   +49 (631) 205-3334, -3331 Fax
Post: FB Informatik - Bau 57, Universitaet KL, W-6750 Kaiserslautern, Germany
From: bketcham@stein.u.washington.edu (Benjamin Ketcham)
Newsgroups: comp.lang.c
Subject: Re: About feof, ferror and return values (Was: Re: changing the contents of a file)
Date: 5 Nov 92 09:47:01 GMT
Article-I.D.: u.1992Nov5.094701.9411
Organization: University of Washington, Seattle


>So, I don't think that using the comma operator is a viable substitute
>for the generalized loop.  Of course, I'm don't really think this is a
>major deficiency in C that needs correcting; there's really nothing
>wrong with using an unconditional for loop with an embedded break.

What's the difference between an unconditional for loop and an unconditional
while loop?

--ben



>----
>Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
>larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
>It's going to be a long year. -- Calvin
Newsgroups: comp.lang.c,comp.lang.c++,comp.lang.pascal,comp.lang.misc