HDTenEightyP/NetNews huggingface dataset:
From: steve@taumet.com (Steve Clamage)
Subject: Re: Reasons for using C vs. Fortran or vice/versa
Organization: TauMetric Corporation
Distribution: usa
Date: Fri, 13 Nov 1992 17:15:42 GMT

mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes:

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

This is a trifle ingenuous, or perhaps just incomplete.

Historically, Fortran was an unstructured language.  To get reasonable
performance, compilers did extensive flow analysis and performed
extensive optimization.  Fortran was run on big machines, and
compilers could take the time and space to do the analysis.  This
tradition of optimization has been carried forward to the present.

Historically, C was a structured language developed on and for small
machines.  Flow analysis was less necessary, and typical machines
were not suitable for large and complex compilers.  Further, the
nature of C and C programming styles made optimization less of a
win (see below).  In recent years, C compilers have begun to do more
optimization.

There are, however, language features which lead to fewer opportunities
for optimization in C than in Fortran.  Fortran doesn't use pointers
the way C does.  Fortran arrays, for example, are first-class objects,
not converted to pointers as in C.  If a C routine uses pointers, the
compiler typically has no way of knowing what any of them point to.
It cannot make simplifying assumptions as in Fortran, since any time
a value is stored through a pointer, the compiler must assume that
almost ANY data value might have been changed.  Example:
	extern double x, y, z;
	void foo(double p[], double q[], int i)
	{
		p[i] = x + y;
		z = x + y + q[i];
	}
Inside foo, p and q might point to the same object, and might point
to x, y, or z.  The first line might have changed the value of x or y,
for example, so the compiler must reload the values of x and y for the
second line, rather than using the remembered sum.  This is the
"aliasing" problem, and dramatically affects the efficiency of
mathematical code in C compared to Fortran.

With the equivalent Fortran code, the subroutine would have array
parameters, and the compiler could assume that the arrays were
disjoint from the global variables x, y, and z.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
From: msb@sq.sq.com (Mark Brader)
Newsgroups: comp.lang.c
Subject: Re: How to use 'return' in c?
Date: 12 Nov 92 06:45:33 GMT
Article-I.D.: sq.1992Nov12.064533.9545
Organization: SoftQuad Inc., Toronto, Canada

> > > I define TRUE as (1==1) because the result of this is a boolean ...
> > No, the result of this is *1*. ...
> No, the result is *represented* by a 1.  "1" is not a boolean value. ...

No, the result *is* 1.  In *math*, the equality operator yields a
Boolean value.  In C, the == operator yields an int value.

It may be correct to say that you don't *like* this fact, but it is
not correct to deny the fact.
-- 
Mark Brader, Toronto		"... one man's feature is another man's bug."
utzoo!sq!msb, msb@sq.com				-- Chris Torek

This article is in the public domain.
Newsgroups: comp.lang.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: Hows this for odd
Organization: SoftQuad Inc., Toronto, Canada
Date: Wed, 11 Nov 92 06:15:08 GMT

> I think using anything other that 0 for FALSE and 1 for TRUE is
> confusing. After all, I would hope that 1 < 3 yields TRUE. And
> for this reason, I never use TRUE and FALSE in my code; 1 and
> 0 are quite clear enough.

Particularly if you choose your names carefully so that it's obvious
when something is intended to yield a Boolean value.  The library
functions isupper, islower, etc., constitute a good example.  (In
ANSI C, fortunately or otherwise, all names beginning with "is" and a
letter are reserved for use as function names, but "is_" is available.)

When I see

	needs_prefix = 1;
and
	if (needs_prefix) ...

I have no trouble knowing that this is Boolean variable.  There are
days when I'd use "= TRUE", I must admit.

> I have been known to write things like:
>    (i == 0) ? 1 : 0
> because even though we all know that boolean expresions are just ints
> and they always have the value 0 or 1, I prefer the mental model of
> booleans being either true or false --- I don't like to use the fact
> that i == 0 is numerically 0 or 1.

My feeling is that if you want a language where Boolean is a distinct
type, you know where to find it.

> I've always thought that expressions like:
>    (i == 0) + (x < y)
> were abusing the language.

"If God had meant Man to fly, He would not have given us the railroads."
If the language designers had meant Boolean to be a distinct type, they
would have made it one.  Of course, you are free to dislike their choice.
-- 
Mark Brader		"Not looking like Pascal is not a language deficiency!"
utzoo!sq!msb, msb@sq.com					  -- Doug Gwyn

This article is in the public domain.
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: single formula for number of bits set in a byte
Date: 5 Nov 92 22:44:03 GMT
Organization: negligable

In article <4202@elwood.prz.tu-berlin.de> pcastine@tubkom.prz.tu-berlin.de (Peter Castine) writes:
>
>There was a whole article on this subject a while ago in a C programming
>journal.
>
>The fastest way is to define a 256-byte long lookup table, a la the isxxx()
>macros.

I don't know what it does to the speed, but if you want to allow
a table, a 16 byte table & a little manipulation goes a long way:

	int countbits(unsigned char c)
	{
		static int tbl[] =  { 0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4 };
		return tbl[(c>>4)&0x0F] + tbl[c&0x0F];
	}

Each nybble can be looked up in the same 16-byte (4-bit) table and
the totals added.

W/ a little analysis of the full 256-byte table, perhaps a mathematical
formula could be derived, there is a definate pattern involved (all
powers of two would be 1 bits, etc.)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Oh I give my life so lightly		|
to my gentle lady.			|	-Richard Hartman	
Giving freely, and completely,		|	hartman@uLogic.COM
for my lady.				|
Newsgroups: comp.lang.c,comp.lang.c++,comp.lang.pascal,comp.lang.misc
From: loegel@fegatello.ssc.gov (George J. Loegel)
Subject: Godel's Proof (was Re: Software design =/= Programming)
Reply-To: loegel@sscvx1.ssc.gov
Organization: Superconducting Super Collider Lab, Dallas, TX
	<1992Nov04.073218.11970@cadlab.sublink.org>
	<1dcuutINNi8t@agate.berkeley.edu> <1992Nov8.031423.16207@ucc.su.OZ.AU>
	<1992Nov9.144550.28811@us-es.sel.de>
Date: Mon, 9 Nov 1992 19:45:31 GMT

From the McGraw-Hill Dictionary of Science and Technology:
Godel's Proof: Any formal arithmetical system is incomplete in the
sense that, given any consistent set of arithmetical axioms, there are
true statements in the resulting arithmetical system that cannot be
derived from these axioms.
--- end of def ---
The trick here is that you use the arithmetical system to encode
information (i.e.  Godel numbering) about proofs and then show (a) no
proof leads to a false statement and (b) you can construct a statement
which says "I have no proof". By (a), (b) must be true, so (b) has no
proof. This leaves us with a true statement we cannot prove.

|> 	The proof is truly wondrous to work through.

The full proof *is* wonderful -- we took six weeks going through it in
class. Also, Raymond Smullyan has just published a book (Oxford Press)
where he gives *three* different proofs of the Incompleteness Theorem.
Smullyan is a wonderful author (e.g. "Forever Undecided : a puzzle
guide to Godel" and "To Mock a Mockingbird") and I recommend any of
the books. 

As for Charles Reindorf's question:
   OK, riddle me this. If I get you right, then if a statement A is
   provably undecidable, you assume that it is true. But if A is provably
   undecidable then so is ~A. This means that *both* A and ~A are assumed
   "true" which is a contradiction. Therefore how can you argue that A
   was "true"? (e.g. you might assume that the axiom of choice were true,
   but you might perversely also assume it were false, I guess).
---- end of quote ---

I believe this is a question about "independent axioms". The best
example of this is Euclid's 5th Postulate (Given a line and a point
outside the line there is exactly one line parallel to the given
line). This postulate gave many mathematicians trouble so they tried
to "prove" it from the remaining axioms. Euclid's 5th Postulate is
"independent" of the other axioms so we can make geometrical systems
where this postulate is *either* true or false but *not* (as you point
out) both.  If we replace the 5th Postulate with "There are *no* lines
parallel to the given line" we get spherical geometry, and if we use
"There are more than one parallel line" we get Lobashevski (or
hyperbolic) geometry.

Another example of an "independent axiom" is the Continuum Hypothesis
with respect to (ZF?) set theory.
--
George J. Loegel
Superconducting Super Collider Laboratory
Accelerator Systems Division
Controls Department -- Software Group
Dallas, TX.
loegel@sscvx1.ssc.gov
Newsgroups: comp.lang.c
From: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: Re: Memory functions  -  memcpy & memmove
Organization: VideOcart Inc.
Date: Mon, 9 Nov 1992 03:56:55 GMT

I've said it before. I could really not give a shit if the code isn't
perfect. I don't get paid to do this, and i try to answer a lot of the  
questions. If someone wants more than a signed int of chars moved, then
change the code. I only want to see replys when the code is just flat
out WRONG.

second, why the hell would it even need to match the ansi code for
memmove. this isnt even called memmove. it was designed to take the 
place of it where it didn't exist yet. Therefore, there isnt a damn
standard to follow. so someone needs to cast (char *) to call this.
I couldn't care less. don't like it, change it. but it works, so 
please quit giving me some B.S. style guide lessons.

ALSO, note that the so called correction missed the point of the code.
the code WILL NOT, let me repeat that, WILL NOT fail if size == 0 initially.
because the first thing in the for loop is size --. this will make it 
-1, and will drop out. Of course, if the size were forced to be unsigned
by some other programmer, then we have a problem. BUT, guess what.
I wrote this, not another programmer. and it works. and if someone
else breaks it by changing a definition without seeing the effects
it has, then GOOD.

Dave Fuller
dfuller@portal.hq.videocart.com
From: ps@cs.strath.ac.uk (Paul Shaw)
Newsgroups: comp.lang.c
Subject: Re: Link Lists - Malloc - Help
Date: 6 Nov 92 08:30:59 GMT
Organization: Comp. Sci. Dept., Strathclyde Univ., Glasgow, Scotland.

In article <Bx72EG.9JG@sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes:
>In <2178@ontek.com> mikey@ontek.com (euphausia superba) writes:
>
>You _can_ avoid making this distinction, if you're willing to throw
>another level of pointers at it:
>
>	zombie = search_list(head);  /* identify item to delete */
>	if (zombie != NULL) {
>		struct item **ptr = &head;
>		while (*ptr != zombie)
>			ptr = &((*ptr)->next);
>		*ptr = (*ptr)->next;
>		free((void*)zombie);
>	}
>
>Is having only one case worth the confusion generated by using pointers
>to pointers?  I really don't know.

I don't think so, its not very easy to read.  Why not just do:

typedef struct DEMO_LIST {
   /* Other stuff */
   struct DEMO_LIST *next;
}DEMO_LIST;

DEMO_LIST *delete_item(l,item) DEMO_LIST *l,*item;
{
   if (l) {
      if (l == item) {
         DEMO_LIST *t;
         t = l->next;   free((void *)l);   return(t);
      }
      else {
         l->next = delete_item(l->next,item);   return(l);
      }
   }
   else {
      /* Getting here means the item did not exist in the list.  You
       * can stick what code you want in here, either return NULL (l) if this
       * is OK or do some error handling stuff.
       */
      return(l);
   }
}

Call this code by:

list = delete_item(list,item);

I also like my list functions returning the new list as this allows things
like:

list = delete_item(delete_item(l,item1),item2);

I don't want to get into a flame war about recursion and efficiency here, but
certainly to me, the recusive version is easier to read (no complex
dereferences etc.), and more likely to be bug free.

Just another view.....

Paul Shaw,
Dept of Computer Science,
University of Strathclyde,
Glasgow.
Newsgroups: comp.lang.c
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: Hows this for odd
Organization: McGill Research Centre for Intelligent Machines
Date: Thu, 12 Nov 92 09:49:05 GMT

In article <1992Nov9.102217.23060@monu6.cc.monash.edu.au>, bena@yoyo.cc.monash.edu.au (Ben Aveling) writes:

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

Of course, it depends on what TRUE and FALSE are.  Someone else already
mentioned what I was going to say, the possibility that TRUE and FALSE
may not be C-context true and false at all but rather (say) boolean
values in a Pascal interpreter.

So I'll just mention some odd code I happened across.  I was
disassembling a binary (you don't want to know why) and found a
sequence that was obviously compiled from a loop something like

	char *s;
	...
	 for (i=0;i<strlen(s);i++)
	  { ...code that doesn't modify the string s points to...
	  }

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: harkcom@spinach.pa.yokogawa.co.jp (Alton Harkcom)
Newsgroups: comp.lang.c
Subject: Re: Productivity of a C programmer ?
Date: 6 Nov 92 00:45:31 GMT
Organization: Yokogawa Electric Corporation, Tokyo, Japan
In-reply-to: Jeff.Tomich@f380.n3603.z1.FIDONET.ORG's message of 29 Oct 92 12:50:12 GMT

In article <464.2AF1567E@mechanic.Fidonet.org>
   Jeff.Tomich@f380.n3603.z1.FIDONET.ORG (Jeff Tomich) writes:

 =}If I'm lucky, maybe a page of good quality code per month. That's if I stop tripping over the power cord in the wee early morining or slipping on books which are lying all over the floor. :-(

   Apparently that page comes in triplicate :)
Newsgroups: comp.lang.c
From: sjs@netcom.com (Stephen Schow)
Subject: To Recurse or NOT to recurse?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 6 Nov 1992 18:51:36 GMT

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?

Thanks in advance
-- 
------------------------------------------------------------------
Steve Schow    | But you don't have to use the claw, if you
sjs@netcom.com | pick the pear with the big paw paw......
               | Have I given you a clue......?
               |                       - Baloo the Bear
------------------------------------------------------------------
Newsgroups: comp.lang.c
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: GCC and all that
Organization: Texas Instruments Inc
Date: Thu, 5 Nov 1992 15:52:39 GMT

In <books.84.0@fsunuc.physics.fsu.edu> books@fsunuc.physics.fsu.edu (Roger Books) writes:

>In article <alien.00qf@acheron.amigans.gen.nz> 
>  alien@acheron.amigans.gen.nz (Ross Smith) writes:
>>A few weeks ago I posted a request for information on how the GNU General
>>Public Licence would affect software I wrote and compiled with GCC. Thanks
>>to everyone who replied, especially Floyd Davidson, who did his level best
>>to explain the Free Software Foundation to me...
>>
>>>
>>>The general consensus among those who seem to know what they're talking
>>>about, though, is that the latter is closer to the truth. Technically,
>>>if I write my own source code, the resulting object code is mine too, and
>>>the compiler writers have no say in the matter. In the real world, though,
>>>a program that actually performs a useful function will always include
>>>linked library code provided as part of the compiler package (yes, Floyd,
>>>I know that's not strictly part of the *compiler* as such, but the
>>>distinction is academic). This library code is, of course, covered by the
>>>FSF's licence (the library licence is slightly different from the
>>>application licence, but in this context the result is the same), and,
>>>therefore, so is the resulting executable.
>>

>So what's the problem?  You tell your customer the program was written in
>gcc and if they want copies of the tools used to build the application 
>you will sell them a copy, including sources, for copying costs.

Hmmm.  I was under the impression that RMS was changing the Copyleft
on the library so as to avoid this 'problem'.  The original Copyleft
made things so that source of YOUR code would have to be provided if
you compiled with GCC (because your product would include Copylefted
code (the libraries) and hence would all fal under the GNU Copyleft).
Can anyone state AUTHORITATIVELY that this has changed?

Of course, if it hasn't changed, simply write your own library code
rather than using that of GCC.  Then no FSF code is included in your
compiled product.  This solution has been taken by a lot of people
(NeXT computer among them, I think).

-- 
"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.
From: fahad@cs.pitt.edu (Fahad A Hoymany)
Newsgroups: comp.lang.c
Subject: How to pass a 2-dim array to a procedure!!
Date: 12 Nov 92 02:07:43 GMT
Organization: Univ. of Pittsburgh Computer Science

First of all I'd like to thank all of you who have been helpfull to us
in so many ways.

Could some one tell me how I can write the procedure line for a function
which accepts a 2-dimensional array without specifying the dimension?

For example: I would like to be able to do this:

int procedure (a[][])    /* Is not accepted by the compiler */

whereas:

int procedure (a[])  /* for a 1-dimensional array is acceptable */

C-less in Pittsburgh
'Help'
Newsgroups: comp.lang.c,comp.lang.c++,comp.lang.pascal,comp.lang.misc
From: behrenss@Informatik.TU-Muenchen.DE (Soenke Behrens)
Subject: Re: Godel's Proof (was Re: Software design =/= Programming)
Organization: Technische Universitaet Muenchen, Germany
Date: Wed, 11 Nov 1992 20:54:15 GMT

mbrown@testsys.austin.ibm.com (Mark Brown) writes:

This is German Nitpiock (tm):

>Shame on you for not recommending GODEL, ESCHER, BACH: An Eternal Golden
>Braid, by Douglas Hofstadter.

The guy is called "Goedel", which is the Duden transcription for the "o" which
is really an "o" with dots above it ... which I can't type because the net does
not (yet??) understand Latin-1 or (even better) 2-byte (4-byte) chars.

Soenke
 ^^
 "o" with two dots above it :)
-- 
===========================================================================
More than silver, more than gold, I need   !    behrenss@informatik.
electricity. I need it for my dreams.      !    tu-muenchen.de
(RACTER)                                   !  FIDO: 2:246/13 Soenke Behrens
From: ede978e@monu6.cc.monash.edu.au (Robert D. Nicholson)
Subject: Re: help with socket
Organization: Monash University, Caulfield Campus
Date: Mon, 9 Nov 1992 02:30:36 GMT

scotth@felix.filenet.com (Scott Hopson) writes:

>In article <00963214.6F76F4C0@vms.csd.mu.edu> 5247cuid@vms.csd.mu.edu writes:
>>Dear Netters:
>>
>>	I have a question regarding the socket. What is it for?
>>I anonymous ftp some demo files. For exmaple,sockdemo.tar.Z.
>>I do not know what to do with it after I decompress and untar it.
>>I can compile the codes in it. But I still do not know how to use 
>>it. Would please give me some help understanding how to use socket.

>Try getting a book on networking n Unix, try reading the man pages on the
>socket call.

>Actually, read the man pages first. You will see that it says that a socket is
>an "end point for communications".

>A good book on Unix networking is "Internetworking with TCP/IP" by Douglas E.
>Comer. It comes in 2 volumes but should help you out quite a bit.



>-- 
>Scott Hopson   (scotth@filenet.com)

Get the paper from the archives, use archie.

The paper is called

socket-primer.shar.Z , you are going to have to tex view the paper but
it has a good introductory start.
From: perera@pollux.cs.uga.edu (Lord Of The Rings)
Newsgroups: comp.lang.c
Subject: lex and yacc spec for Concurrent C ?
Date: 7 Nov 92 05:33:05 GMT
Article-I.D.: athena.1992Nov7.053305.1385
Distribution: na
Organization: University of Georgia, Athens
Originator: perera@pollux

Folks,

Does anybody know where I can get a lex, and yacc file on
Concurrent C ?

Thanks,

- Niranjan

-- 
 _   /|   perera@pollux.cs.uga.edu | Comp Sci Dept, Univ of Georgia. 
 \'o.O'   "yer about to be boarded, ye scurvy network news dogs! har har ..."
 =(_^_)=               -- Oliver Wendell Jones, Bloom County Hacker & Cracker
    U  
Newsgroups: comp.lang.c
From: dfuller@portal.hq.videocart.com (Dave Fuller)
Subject: Re: problem with foef()
Organization: VideOcart Inc.
X-Newsreader: Tin 1.1 PL3
Date: Thu, 12 Nov 1992 19:51:54 GMT

U17868@uicvm.uic.edu () writes:
: i
: I am reading a binary file with fread. The file has only two records each of si
: ze 193 bytes. The problem is that after reading the second record (structure) t
: he feof function does not detects the end of file and goes through the loop one
:  more time (third time). I check with the ftell fucntion the position of the
: file_pointer (pointer to the file that I am reading). First time it gives the p
: osition at 193 i.e after reading the first record. Second time it shows the pos
: ition of the file_pointer at 386 which is correct. Now, I don't have any more r
: ecords in the file. But, it goes again and reads the same last record again. Th
: e position of the file_pointer is still 386. After reading the same record, feo
: f detects the end of file and returns.  any suggestions
: thanks in advance
: u17868@uicvm.cc.uic.edu
: sikander
:  my program is listed below
: 
: #include "header.h"
: void dispdail(date)
: char date[9];
: {
: int i,j, a;
: FILE *file_pointer;
: struct activity temp;
:  file_pointer = fopen("activity.dat","rb");
:  fseek(file_pointer,0,0);
: 
:        while(!feof(file_pointer))
:   {
:     fread(&temp, sizeof(temp),1,file_pointer);
:     j = strcmp(date,temp.date);
:     if(j == 0)
:         printf("%s",temp.date);
: 
:      if(a = (feof(file_pointer)) != 0)
:         {
:          fclose(file_pointer);
:          return;
:         }
:   }/* end while */
: 
: }   /* end dispdail */

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.

also fread returns the number of elements read, you don't check this value.

here is what i believe happens:
after the 2nd read, feof doesn't return non-zero
fread can't read the element and returns a 0 for # of elements read
   (it is at this point that the file pointer is positioned at the EOF)
   ( also fread won't null the buffer. if it reads 0 items, it leaves
     the buffer intact. this is why you see all of the information from
     the 2nd read a 3rd time)
the next feof does try to read past EOF and the boolean test works.


what you will want to do to guarantee success is to test the return
value of fread also.

Dave Fuller 
dfuller@portal.hq.videocart.com

Newsgroups: comp.lang.c