HDTenEightyP/NetNews huggingface dataset:
From: tsmith@CS.Stanford.EDU (Todd Michael Smith)
Subject: Re: Fortran to C conversion: Why bother?
Organization: Computer Science Department, Stanford University.
Date: Tue, 10 Nov 1992 18:08:18 GMT

In article <BxIEwH.F59@netnews.jhuapl.edu>,
          ygor@aplexus.jhuapl.edu (Daniel E. White  (F2C)) writes:
|> 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.
|> |>
|> |> -Hugh
|> 
|> I second that.  I've seen too much C source that looks like FORTRAN with
|> semi-colons appended to the line endings.
|> 

What if you don't have a FORTRAN compiler?

What if you have a special C compiler (bought or built yourself) that
performs optimizations that you would like to use on FORTRAN code also?

What if you want to move a program into C, but would rather automatically
translate and then modify the code than rewrite or translate the whole
thing by hand?

-- 
Todd Smith                                    tsmith@cs.stanford.edu
                    Life is a word problem.
Newsgroups: comp.lang.c
From: jamull01@starbase.spd.louisville.edu (Mr. Positive)
Subject: Reading unsigned char ?
Date: Mon, 9 Nov 1992 07:18:00 GMT
Organization: University of Louisville

      I am trying to use sscanf to read an unsigned character from an ASCII
   file.  The only catch is whats in the file is not the ASCII character but
   a decimal integer.  If I try to read an integer into an unsigned character
   I don't get anything.  If anybody has any advice to offer I would appreciate
   it.
From: tal691@huxley.anu.edu.au (Tonio Loewald)
Newsgroups: comp.lang.c
Subject: A Modest Proposal
Date: 11 Nov 92 01:43:22 GMT
Organization: Australian National University
NNTP-Posting-Host: 150.203.2.12

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

My modest proposal is that a programmer SHOULD count lines of comments
towards the mystic productivity value (whatever it is). Sure, you
can argue (as shown below) that TOO MANY COMMENTS can be a bad
thing. But, so can TOO MUCH CODE (or, in the case of some programmers,
*any* code).

Whether you count comments separately from "real" code is a separate
issue. You could start discounting simple assignment statements
or counting lines involving nested function calls with casting as
either 2 lines of code or -10 lines of code depending on your
outlook. Or defining 10 lines of assembler as 3 lines of "code"
or whatever.

The important point is that if you DON'T count comments, that 
means that you don't think of them as VALUABLE. This reflects
a dangerous mindset.

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

Again -- I don't think this is any more true than saying that if
there's a lot of code, the program must be badly written. Sometimes
a single assignment statement needs a LOT of documentation. (Eg.
"don't touch this assignment statement unless you FULLY understand
what it does. A synopsis follows...")

Simple arithmetic can't tell good comments from bad any more than
it can tell good code from bad.

Anyone out there using WEB like to comment on any of this?

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

Interesting to consider the effects on programmer "productivity" of using
different languages, formatting, naming conventions, and so on.

Tonio 

-- 
Tonio Loewald            | Ph  06 290 1594 | 13 Sabine Cl. Garran
tal691@huxley.anu.edu.au | Fax 06 290 1595 | ACT 2605   AUSTRALIA
"You can lie/You can cry/For all the good it'll do you, you can
die/But when it's done/And the police come/And they lay you down
From: wenner@einstein.eds.com (Rich Wenner)
Newsgroups: comp.lang.c
Subject: Re: problem with foef()
Date: 12 Nov 92 21:38:24 GMT
Organization: Electronic Data Systems

In article <BxMCIJ.L8M@portal.hq.videocart.com> dfuller@portal.hq.videocart.com (Dave Fuller) writes:
>U17868@uicvm.uic.edu () writes:

>: I am reading a binary file with fread. The file has only two records, each
>: 193 bytes. The problem is that after reading the second record (structure)
>: the feof function does not detect the end of file and goes through the loop
>: one more time (third time).

>:   while(!feof(file_pointer))
>:   {
          [fread() call and other processing omitted]
>:   }/* end while */

And confusion soon follows.

>a couple of things. feof returns non-zero after the first attempt to read
>PAST the end of the file. possibly you have a spare char out there that
>makes it NOT a read past EOF.

NO!!!  You don't have to have any 'spare' characters to explain the behavior
of this code.  The second read reads UP TO the end, not past it.  Even without
spare characters, this is not sufficient to make feof() return a true value.
This is why I tell my students not to use feof() for loop control.  Instead,
I recommend a structure like the following:

    while ( fread( buffer, element_size, num_elems, file ) == num_elems )
    {
        /* process the stuff we read */
    }

    if ( feof( file ) )
    {
        /* ok, we finihsed the whole file */
    }
    else
    {
        /* uh-oh, something went wrong */
    }

-- 
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: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: Re: Hows this for odd
Organization: VideOcart Inc.
X-Newsreader: Tin 1.1 PL3
Date: Mon, 9 Nov 1992 19:00:34 GMT

bena@yoyo.cc.monash.edu.au (Ben Aveling) writes:
: 
: Hi all,
: 
: Just recently I saw the following fragment of code, and I thought I'd share
: it with you all.  (This is real code, part of a real program people will
: pay money for.)
: 
: 	... ,(i==0)?TRUE:FALSE,...
: 
: Am I going mad, or is this slightly redundant ?
: 
: 	:-/  Ben

Not at all. Depends on what TRUE & FALSE are, and what they mean to the
calling function. possible that TRUE is defined as -1, FALSE as -2. 
0 does not always mean TRUE. actually i prefer to always give a TRUE and FALSE
definition and return them from all functions. this way code is more
readable and checking return values (func() == 0) vs (func() == TRUE)
is much easier this way.

Dave Fuller
dfuller@portal.hq.videocart.com

Newsgroups: comp.lang.c
From: pinard@IRO.UMontreal.CA (Francois Pinard)
Subject: Should I support <stdarg.h>?
Organization: Universite' de Montre'al
Distribution: comp
Date: Thu, 12 Nov 1992 02:09:23 GMT

Hi, People.  I need your advice and help.  Please email me directly.
I'll summarize on request.

For the next release of GNU m4, which currently uses <varargs.h>, I
need to know if there are C compilers floating around which do not
have <varargs.h>.  I have access to some ANSI compilers, they all
support both <stdarg.h> and <varargs.h>, so I see no need for real
<stdarg.h> support.

Also, is there any C compiler for UNIX which have neither <stdarg.h>
nor <varargs.h> at all?  If yes, how do you proceed with these?
--
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!
Newsgroups: comp.lang.c
From: jrv@truth.mitre.org (Van Zandt)
Subject: Re: The Correct Way To Write C if-Statements
Organization: The MITRE Corp., Bedford, Ma.
Date: Thu, 12 Nov 1992 17:55:58 GMT

In article <1992Nov12.140710@gese.ge14.mdadv.gv.at> sca@gese.ge14.mdadv.gv.at (Petzi Schweda) writes:
>To avoid another discussion: I like to have the 
>paranthesis under each other VERY much, especially
>the opening and closing ones. 

...especially if one's editor has a command to toggle the cursor between
matching braces.  If they are in different columns, some error has crept in.

                               - Jim Van Zandt
From: droelke@rockdal.aud.alcatel.com
Newsgroups: comp.lang.c
Subject: Re: Line drawing algorithm
Keywords: C, graphics, line
Date: 4 Nov 92 22:45:34 GMT

michalek@ux1.cso.uiuc.edu (Libor Michalek) writes:

>sava4711@mach1.wlu.ca (ken savage u) writes:

>>  Here's my problem:  I'm trying to find a fast line-drawing algorithm (in C)
>>for VGA graphics mode.  The problem is not placing the pixel on the screen,
>>but rather deciding WHERE to put it.  I've thought up of several ideas, given

>Heres a fairly fast line draw ing algorithm


You might also want to check out the latest DDJ.
From: wells@cdsmn.mn.org (Rich Wells)
Subject: Re: A Modest Proposal
Organization: Dicomed, Inc
X-Newsreader: TIN [version 1.1 PL6]
Date: Wed, 11 Nov 1992 16:07:19 GMT

Tonio Loewald (tal691@huxley.anu.edu.au) wrote:
: Quoting me (Rich Wells) without attribution:
: >>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
: 
: My modest proposal is that a programmer SHOULD count lines of comments
: towards the mystic productivity value (whatever it is). Sure, you
: can argue (as shown below) that TOO MANY COMMENTS can be a bad
: thing. But, so can TOO MUCH CODE (or, in the case of some programmers,
: *any* code).
: 
: Whether you count comments separately from "real" code is a separate
: issue. You could start discounting simple assignment statements
: or counting lines involving nested function calls with casting as
: either 2 lines of code or -10 lines of code depending on your
: outlook. Or defining 10 lines of assembler as 3 lines of "code"
: or whatever.
: 
: The important point is that if you DON'T count comments, that 
: means that you don't think of them as VALUABLE. This reflects
: a dangerous mindset.

You misunderstood me.  I think comments ARE valuable.  I've had
to maintain enough old code in my life that I now know how to
comment code thoroughly, usefully, and completely, so that those
who come after me don't have to go through a lot of the counter-
productive crap I had to go through to understand some of the
code I have dealt with.

My point was that (1) comments should be counted separately from
code, not ignored completely, and (2) there should be documentation
external to the code which provides an overview of the big
picture.  In other words, just counting in-source comments is not
enough; there should be external documentation, the quality and
amount of which must also be taken into account.

Too many programmers seem to think that commenting their code
is enough.  In-source comments are great for explaining the
small picture, but other documentation is necessary to show how
the whole system fits together.  Not to mention the fact that
such documentation is even useful if written before any coding
is even started.

BTW, this is the second time in the last coupla months that I
have been accused on the net of having a "dangerous" mindset.
I'm beginning to take "dangerous" as a compliment.
-- 

Richard Wells  wells@cdsmn.mn.org  or  ...!tcnet!cdsmn!wells
Date: Wed, 11 Nov 92 08:34:00 +0100
From: Gilles_Kohl@spam.fido.de (Gilles Kohl)
Subject: Hows this for odd
Newsgroups: comp.lang.c
X-Comment-To: (Ben Aveling)
Organization: To take arms against a C of troubles ... 

    ... ,(i==0)?TRUE:FALSE,...

 > Am I going mad, or is this slightly redundant ?
Yes. :-)

Depends on how TRUE and FALSE are defined, of course. If you want to 
absolutely, certainly and securely stomp out, abolish and exterminate 
redundancy, replace by !i.

Regards,
Gilles.

---
Newsgroups: comp.lang.c
From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)
Subject: Re: Reasons for using C vs. Fortran or vice/versa
Organization: Department of Chemistry, University of Toronto
Distribution: usa
Date: Thu, 12 Nov 1992 21:01:51 GMT

In article <1992Nov12.135901.15191@ccd.harris.com>
djulian@controls.ccd.harris.com (Danny E. Julian) writes:
>I was wondering what advantages Fortran has over C(if any) and vice-versa.

     To some of us, Fortran's built-in complex math is extremely
useful.  Nothing else matches Fortran's complex handling for speed and
simplicity.

>I know C is much better than Fortran in the I/O dept., but is there anything
>else that makes it a better language.

     To me, the main advantage of C over Fortran is that the former
allows interesting data structures (since it has pointers and dynamic
memory allocation) while in the latter, arrays are about all you get.
On the other hand, Fortran arrays are a lot easier to handle than C
arrays.  (For proof of this, just consider how often you hear people
around here ask about array handling compared to the frequency of
similar queries in comp.lang.fortran.)

>The reason I ask is when was in college, we used C for our primary language.
>But the company I work for, uses a lot of Fortran(mainly because it was
>written years ago and still works).  We do a lot of number crunching around
>here and I've always been told that Fortran was very good at that.

     It is easier to write Fortran that a compiler will properly optimize
than it is to write optimizable C.  One chap at HP has a trivial routine
that the Fortran optimizing compiler immediately recognizes and does the
right thing with, but which needs to be heavily modified to obtain good
performance in its C version.  I can display this code fragment if there
is sufficient interest.

				Marc R. Roussel
                                mroussel@alchemy.chem.utoronto.ca
Organization: University of Illinois at Chicago
Date: Mon, 9 Nov 1992 23:59:28 CST
From: <U17868@uicvm.uic.edu>
Newsgroups: comp.lang.c
Subject:    using variables of type date in UNIX

I want to know how I can use the variable of type date in C. For example, how c
ould I define a varaible like
"todays_date" to be of type date and then read the input in the format like
                       11/09/92
 I would be using ANSI C on UNIX. Is there any biult in function in C library t
hat would allow me to declare a variable of type date . If the type date is a U
NIX system command, how can I use it in my C program. Could I use it by definin
g enumerated data type. If so, how?

thanks,
email: u17868@uicvm.cc.uic.edu
Sikander Waheed.
Newsgroups: comp.lang.c
From: goudreau@batman.rtp.dg.com (Bob Goudreau)
Subject: Re: The Correct Way To Write C if-Statements
Date: Thu, 12 Nov 92 21:32:28 GMT
Organization: Data General Corporation, RTP, NC

In article <hansg.721510062@risken> hansg@risken.vd.volvo.se (Hans Granqvist) writes:
>goudreau@robin.rtp.dg.com (Bob Goudreau) writes:
>
>->	if ( OpenCode ) ...
>
>-Is anyone else as repelled as I am by the practice of leaving the
>-parentheses surrounded by whitespace on both sides?  Not only does
>-it violate such de-facto standards as K&R or H&S, it goes against
>-common English usage as well ( and if you don't believe that, then
>-tell me what's wrong with this parenthetical question? ) .
>
>Hmm... in my opinion, every person putting two (2) spaces at the end of
>a sentence ('full stop'?) not only breaks a de facto Swedish standard but also
>shows great unsolidity in his language. 

"Unsolidity in his language"?  Whatever does that mean?

Anway, if I were posting in Swedish, then perhaps I'd put only one
space after each period.  But in English, two following spaces *IS*
the standard (look it up).   And (getting back to the point), I'll
bet that even in Swedish you don't insert gratuitous spaces between
parentheses and the clause which they surround.


>-Moving on to another topic...
>
>->	if ( SomeDarnThing == TRUE ) ...
>
>-If "SomeDarnThing" (amazing how the whitespace fanatic seems to hate
>-underscores!) is a boolean variable, then what is the point of testing
>-it against TRUE or FALSE?  The following is more concise and easier
>-to read:
>
>-	if (some_darn_thing) ...
>
>
>Aye, relating to your latest remark on coherence with common language
>usage, is your proposed fashion more correct than the other? 

I don't understand this comment.  The presence or absence of the
"== TRUE" code has no connection with punctuation conventions at all.
The thing which I find objectionable is the silly testing against
TRUE or FALSE.  Certainly the practice of using

	if (condition)

instead of

	if (condition == 1)  /*  or == TRUE */

is well established in C; look at K&R1.  So why add needless
verbiage?


>And, then, is there the slight casuality that 'TRUE' was defined to, per
>chance, '4711'?

In which case there is the large *certainty* that the coder doesn't
know what he is doing! Anyone who defines TRUE and FALSE such that
(! TRUE) isn't equal to FALSE or (! FALSE) isn't equal to TRUE
shouldn't be coding in C.  The only pair of values that meets both
conditions is 1 and 0, and the only mapping that allows use of C's
natural flow-control is when FALSE == 0.

----------------------------------------------------------------------
Bob Goudreau			Data General Corporation
goudreau@dg-rtp.dg.com		62 Alexander Drive	
+1 919 248 6231			Research Triangle Park, NC  27709, USA
From: uyeno@subsys.enet.dec.com (Alice Uyeno)
Newsgroups: comp.lang.c
Subject: need to create a jump table 
Date: Tue, 3 Nov 1992 02:52:10 GMT
Reply-To: uyeno@subsys.enet.dec.com (Alice Uyeno)
Organization: Digital Equipment Corporation


Hi,

I'm trying to develop a jump table.  Actually, the scenario is that I have two jump tables.  Depending on the value of a certain flag, I use one or the other.  Each jump table consists of pointers to functions.  I'm wondering if it is possible to have the functions with varying number of parameters.  For example, if my jump table contains pointers to ErrorRoutine and ValidateCmd, where the prototypes for the routines are as follows:

	void ErrorRoutine(int *ErrCode, struct foo * MyPtr);
        void ValidateCmd(struct foo * CmdPtr);

void (* FcnTbl[])() = {ErrorRoutine,ValidateCmd};

where 
	ptr = FcnTbl;

and ptr is how the jump table is referenced.
Newsgroups: comp.lang.c
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: Memory functions  -  memcpy & memmove
Organization: Sequoia Peripherals, Inc.
Date: Sat, 7 Nov 92 16:50:47 GMT

In article <BxB88A.1Au@portal.hq.videocart.com> dfuller@portal.hq.videocart.com (Dave Fuller) writes something like this about memmove:

   if (source > dest) {
      for(;size > 0; size --)
         *dest++ = *source++;
   } else {
      for(size --; size >= 0; size --)
         dest[size] = source[size];
   }

I'd recommend the same thing with the caveat that this is not ANSI
standard code and will not work on some systems. In fact, there is
no reasonable way to write memmove in standard C; this is why the
standard added this function.

The problem with the above code is that it is not legal to compare
two pointers (except for equality) unless the pointers point into
the same object. Such comparisons give undefined behavior which
means it can do anything at all it wants.

That being said, I wouldn't worry too much about this problem. On
any reasonable system (except one that is specifically designed
to hunt down non-portabilities in code) this should work. All that
is required is that the computer always return *some* answer when 
comparing two pointers, that it not core dump or explode or something.

Because if the two pointers point into the same object the above
code works. That is, after all, what it was designed to do. And if
the two pointers don't point into the same object, then there is
no problem with overlapping regions and you can copy either way
you want to. Either way, you're covered.



-- 
Dave Eisen                               Sequoia Peripherals: (415) 967-5644
dkeisen@leland.Stanford.EDU              Home:                (415) 321-5154
       There's something in my library to offend everybody. 
          --- Washington Coalition Against Censorship
From: paul@music.sie.arizona.edu (Paul J. Sanchez)
Newsgroups: comp.lang.objective-c
Subject: gcc-2.3.1
Keywords: Run-time support
Date: 5 Nov 92 18:25:25 GMT
Organization: University of Arizona UNIX Users Group

Has anyone succeeded in getting the run time libraries to work in the  
latest release of Gnu CC?  I'd like to try it out on my students, but  
haven't been able to make it work yet.

--paul
paul@sie.arizona.edu
Xref: sparky comp.lang.objective-c:661 comp.lang.smalltalk:2275 comp.object:4188
From: lozinski@cup.portal.com (Christopher A Lozinski)
Newsgroups: comp.lang.objective-c,comp.lang.smalltalk,comp.object
Subject: Smalltalk Interface to Objective-C (Product Announcement)
Date: Tue, 10 Nov 92 21:05:16 PST
Organization: The Portal System (TM)
Distribution: world

PRODUCT ANNOUNCEMENT

     The Smalltalk Interface to Objective-C makes Objective-C
objects look like Smalltalk objects.  The interface is based on the
simple concept that every remote Objective-C class and instance can
be represented by a local Smalltalk proxy object.  Messages sent to a
local Smalltalk proxy object are transparently forwarded to the
actual Objective-C object it represents, and the results are returned
as Smalltalk objects.  To the Smalltalk developer, there are just
Smalltalk messages being sent to Smalltalk objects.  To the
Objective-C developer, there are just Objective-C messages being sent
to Objective-C objects.  The net result is that the two languages are
very smoothly integrated.  

     No longer do developers have to choose between using Objective-C
or Smalltalk; they can use both languages together, each where it is
best suited.  Prototypes can be quickly implemented in Smalltalk, and
performance-critical code can be developed in Objective-C. 
Alternatively, portable applications engines can be written in
Objective-C, moved to the platform of choice, and integrated with a
new interface quickly developed in Smalltalk.  Existing Smalltalk
interface building tools can be used, while existing Objective-C
libraries can be reused.

     The product is currently shipping under Microsoft Windows.  It
comes bundled with the Borland Extensions to Objective-C.  For
further information please send your postal address, telephone
number, and preferred platform to:

Berkeley Productivity Group
35032 Maidstone Court
Newark, CA 94560, USA
Tel:(510) 795-6086  
Fax:(510) 795-8077
CompuServe:71201,1175  
Internet:lozinski@cup.portal.com
Newsgroups: comp.lang.objective-c