HDTenEightyP/NetNews huggingface dataset:
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Subject: Re: Software design =/= Programming
Originator: sasghm@theseus.unx.sas.com
Date: Fri, 6 Nov 1992 14:15:54 GMT
Organization: SAS Institute Inc.


In article <1dcuutINNi8t@agate.berkeley.edu>, faustus@ygdrasil.CS.Berkeley.EDU (Wayne A. Christopher) writes:
|> In article <1992Nov04.073218.11970@cadlab.sublink.org> martelli@cadlab.sublink.org (Alex Martelli) writes:
|> > The point of Goedel's Theorem is, that for *ANY* formal system "powerful
|> > enough" ... there will be *true* statements about the formal
|> > systems that cannot be proven from that set of axioms!!!
|> 
|> Not exactly -- what it says is that for any set of axioms A there will
|> be statements S such that A does not imply S and A does not imply not
|> S.  The notion of truth doesn't come into it, since in a formal system
|> either something is provable or isn't.
|> 
|> 	Wayne

Since the systems in question are classically two-valued, then either
S is true or ~S is true.  While what you say about Goedel's theorem
is correct, truth *does* "come into it" quite easily.  See Tarski's
theorem.
-- 
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Random Number Generator
Date: 8 Nov 1992 10:58:19 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

>In article <26939@dog.ee.lbl.gov> I wrote:
>> Time for another Netnews Rerun....

In article <1992Nov6.223901.11603@athena.mit.edu> scs@adam.mit.edu
(Steve Summit) writes:
>Chris may be thinking of an earlier draft.  The example
>implementation in the published ANSI standard (ANSI X3.159-1989,
>sec. 4.10.2.2, p. 155) is not a pure linear congruential random
>number generator; rather, it is a LCRNG with a 32-bit (or more)
>state value which returns 15 bits from the *top* (most
>significant) half.  Therefore, its actual return values are
>*not* subject to these particularly unfortunate regularities.
>(To recap: the low-order N bits of a pure LCRNG repeat with
>period 2-to-the-N.)

Several comments:

This is a problem with netnews reruns:  They get out of date.  I try to
take time to edit them, but....

The parenthetical recap is not quite right.  Rather, given an LCRNG
of the form:

	X[i+1] = (X[i] * a + c) mod m

(which has period <= m; if a and c are well-chosen, the period is
exactly m), we define a new sequence:

	Y[j] = X[j] mod d

If m is congruent to 0 mod d (i.e., m % d = 0), the sequence in Y
will repeat with period <= d.  The definition of Y corresponds
perfectly with taking rand() % d (think of X[j] as the j'th return
value from rand()).

Since typical C implementations of rand() use LCRNG's with 2^k (for
integer k, usually 16 or 32) as their `m', and since 2^k mod 2^N is 0,
the low order bits repeat with period 2^N.  But this only holds when
m = 2^k, not for LCRNG's in general.

>In other words, the prevailing advice is to consign rand() % N to
>the same dustbin that gets() has been demoted to: the code is
>there, and it is theoretically legal to use it, but you mustn't.

Right.

>I happen to think that the rand() % N problem is so common, and is
>so easily made by the unwary, that it's worth fixing ...

This is rather difficult (see your own note 2).  For what it is worth,
I ran a few simple 2-d scatter plot tests on the `ANSI C' generator
(which, incidentally, appears below), and saw no obvious patterns, but
I would want to know more about it before trusting it much.

/* ANSI C `portable random number generator' */
static unsigned long int next = 1;

int rand(void)		/* RAND_MAX assumed to be 32767 */
{
	next = next * 1103515245 + 12345;
	return (unsigned int)(next / 65536) % 32768;
}

void srand(unsigned int seed)
{
	next = seed;
}
-- 
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: bandy@netnews.jhuapl.edu (Mike Bandy)
Subject: Re: Novice wants to pass type double to function
Organization: JHU/Applied Physics Laboratory
Distribution: usa
Date: Sat, 7 Nov 1992 05:39:54 GMT

sutton@lamar.ColoState.EDU (Rich Sutton) writes:

>As a first approximation I tried to recreate the power.c program in
>Kernighan & Ritchie's 2nd edition. (This is on p24 if you have it handy.)
>This program passes 2 variables of type int and returns type int. As
>written in K&R SunOS cc won't compile it!? I thought ANSI C was supposed
>to be portable? What am I doing wrong? Here is the file after doing
>"cc power.c |& error" :


>#include <stdio.h>

>/*###3 [cc] syntax error at or near type word "int"%%%*/
>int power(int m, int n);

>main()
>{
>	int i;

>	for (i = 0; i < 10; ++i)
>		printf("%d %d %d\n", i, power(2,i), power(-3,i));
>	return 0;
>}

>/*###14 [cc] syntax error at or near type word "int"%%%*/
>int power(int base, int n)
>{
>	int i, p;

>	p=1;
>/*###19 [cc] n undefined%%%*/
>	for (i = 1; i < n; ++i)
>/*###20 [cc] base undefined%%%*/
>		p = p*base;
>	return p;
>}

The problem is that the C compiler is not ANSI!  Defining the parameter type
like you do is an extension added when the language was made ANSI and was not
part of the original C.  See the 1st edition of the K+R book.

Convert the routine declaration of

    int power(int base, int n)
    {

to

    int power(base, n)
    int base, n;
    {

Likewise in your floating point routines to pass double, define your routines
as:

    double myroutine(a, b)
    double a, b;
    {
        ...

-- 

	Mike Bandy
	bandy@aplcomm.jhuapl.edu
	Johns Hopkins University / Applied Physics Lab
Newsgroups: comp.lang.c
From: tim@tim.src.utah.edu (Tim Ma)
Subject: Detecting DOS redirection
Organization: University of Utah
Date: Fri, 13 Nov 1992 01:18:21 GMT


This may be a pretty easy question (it seems like it might), but the answer 
eludes me.

Is there anyway to detect in a C program whether the user has redirected the 
output of that particular program using DOS redirection (>)?

Thanks,

Tim Ma
Associate Programmer
University of Utah
Email:  tim@src.cppa.utah.edu

Newsgroups: comp.lang.c
From: n087ec@tamuts.tamu.edu (Hessel Kooistra)
Subject: Looking for Jim Bumgardner, author of Lasrflow
Organization: ~/lib/organization
Date: Wed, 11 Nov 1992 17:29:04 GMT

I am looking for Jim Bumgardner, the author of Lasrflow, a flowchart
maker available on Simtel.  He seems to have moved from his apartment
address of 1988.  Has anyone seen him?  Thanks.

    Hess
From: mgream@acacia (Matthew Gream)
Newsgroups: comp.lang.c
Subject: Re: Need help reading floats from file
Date: 8 Nov 1992 22:09:21 GMT
Organization: University of Technology, Sydney
NNTP-Posting-Host: acacia.ccsd.uts.edu.au
X-Newsreader: Tin 1.1 PL5

Charles Evans (cee1@Ra.MsState.Edu) wrote:

: Ok, in getting data for an experiment to look at, I have
: 200 .xx floating point number, just a decimal point and 2 decimal
: places, put in 20 x 20 in a data file.
: 
: How can I read them into an array.. all i could think of was do 
: a HUGE fgets/sscanf thing with "%f %f ... %f".. 20 times and put into
: 20 parts of an array like : value[i++][j] on an on until i=20 then
: reset i and increment j..
: 
: but i get weird errors from dos and qemm.. something is wrong.
: why cant i (i can in basic :)) just keep reading in a floating point number
: or read it in as a small string until the first whitespace?
: 
: or something. thanks
: 
: data file looks like:
: 
: .11 .33 .00 .......
: .23 .45 .23 .......
:  .   .   .
:  .   .   .
: 
: 20 x 20

 Try using strtok() and atof(), for example, your code could look
something like:

   FILE *FILE_handle;
   char Buffer[MAXBUFLEN];
   int  row, column;
   double big_array[MAX_ROWS][MAX_COLUMNS];
 
   row = 0;
   while( fgets(Buffer,sizeof(Buffer),FILE_handle) && (row < MAX_ROWS) ) {
      register char *char_ptr;
      if(! (char_ptr = strtok(Buffer," \t\r\n")) ) 
	continue;
      column = 0;
      while( char_ptr = strtok(NULL," \t\r\n") )
          big_array[row][column++] = atof(char_ptr);
      row++;
   }
 
 That may or may not be what you want, but it should give you some
good ideas. The reason qemm is probably barfing is that your passing
an incorrect pointer (or something to that effect) in sscanf.

Matthew.
--
M.Gream@uts.EDU.AU - Matthew Gream - 'Edges have holes next to them .. '
Newsgroups: comp.lang.c
From: alpha@waggen.twuug.com (Joe Wright)
Subject: Re: pointer explanation
Organization: ALPHA, Box 68621, Va. Beach, VA 23455
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 5 Nov 1992 04:18:03 GMT

John C. Lusth (jcl@bdrc.bd.com) wrote:
: I am teaching an introductory course in C.  One of my students,
: working on a programming assignment, posed me a question.
: 
:     Why would the following lines of code generate
:     an error message that states "value has no
:     members"
: 
:     " if((strcmp (*records[min].last, *records[j].last)) > 0) "
: 
:     OR
: 
:     " if((strcmp (records[min].last, records[j].last)) > 0) "
: 
:     where records is a struct entry **.
: 
: 
: 
: The layout of the data structure the student is dealing with is...
: 
: 		 ___________________________________
:     records---->|_____|_____|_____|_____|_____|_____|
: 		   |     |
: 		   |     |
:         -------    |     |
:        | first |   |     |
:        |-------|   |     |
:        | last  |<--      |
:        |-------|         |
:        | age   |         |
:         -------          |
:               -------    | 
:              | first |   |
:              |-------|   |
:              | last  |<--
:              |-------|
:              | age   |
:               -------
: 
: The answer I gave was...
: 
:     Given
: 
: 	struct entry **records;
: 
:     then
: 
: 	*records[i].last
: 
:     is wrong because * binds tighter than [], so the above is really
: 
: 	(*records)[i].last
: 
:     which devolves to
: 
: 	*((*records) + i).last
: 
:     This is wrong because records holds the address of the first
:     element of the array, which is the address of a structure.   You
:     are saying, get the first address in the array and add i to it.
:     Well, the first address does not point to an array so it makes no
:     sense to add an offset.  It is the address of a structure. What you
:     really want is
: 
: 	*(records[i]).last
: 
:     which devolves to
: 
: 	*(*(records + i)).last
: 
:     Now you are getting the address in the ith element of the array and
:     then following the pointer.
: 
:     The code
: 
: 	records[i].last
: 
:     is clearly wrong because records[i] is of type pointer to struct
:     entry, not struct entry, so it has no members.
: 
: 
: It seems to me that I didn't do a very good job in explaining the
: difference, at least for the first code fragment.  Would anyone care
: to try a more succinct and clear headed explanation I can pass along
: to my student?
: 
: john
: -- 
: John C. Lusth, Becton Dickinson Research Center, RTP, NC, USA  jcl@bdrc.bd.com

It's all 'wrong'.  Your graphic indicates an array of structs with records
pointing to the array.  If so, the declaration is 'struct entry *records;'
and 'records[i].last' is right.  If 'struct entry **records;' is right
then your graphic is all wet.  In this case, records[i] is a pointer,
not a structure.  Use 'records[i]->last' or (*records[i]).last

Finally, * does not bind tighter than . [] -> or ().  These are the tightest.

-- 
Joe Wright  alpha@waggen.twuug.com
From: hansg@risken.vd.volvo.se (Hans Granqvist)
Newsgroups: comp.lang.c
Subject: Re: The Correct Way To Write C if-Statements
Date: 11 Nov 92 19:27:42 GMT

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. 


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

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

--
Hans Granqvist, Volvo, Gothenburg, Sweden.
Newsgroups: comp.lang.c
From: goudreau@robin.rtp.dg.com (Bob Goudreau)
Subject: Re: The Correct Way To Write C if-Statements
Date: Fri, 6 Nov 92 22:56:22 GMT
Organization: Data General Corporation, RTP, NC

In article <140742@lll-winken.LLNL.GOV> booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes:
>
>		The Correct Way To Write C if-Statements
>				by
>			    Jim Minton

Oh, the hubris!  So there is only One True Way to write them, eh?


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

What's wrong with keeping the parentheses tightly-bound to the
contents they enclose?  That is, why not stick with the following
tried-and-true style:

	if (conditional_expression) ...



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

Anyway, if you open the explicit-testing-against-TRUE can of worms,
where does it end?  One might just as well say

	if (((SomeDarnThing == TRUE) == TRUE) == TRUE) ...

... and so on.

----------------------------------------------------------------------
Bob Goudreau			Data General Corporation
goudreau@dg-rtp.dg.com		62 Alexander Drive	
+1 919 248 6231			Research Triangle Park, NC  27709, USA
Newsgroups: comp.lang.c
From: ygor@aplexus.jhuapl.edu (Daniel E. White  (F2C))
Subject: Re: Fortran to C conversion: Why bother?
Organization: Johns Hopkins U. Applied Physics Lab
Date: Tue, 10 Nov 1992 16:53:05 GMT

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.

-- 
------------------------------------------------------------------------
                                                               Dan White
------------------------------------------------------------------------
"Sometimes  I  think  the  surest  sign  that  intelligent  life exists
 elsewhere  in the universe is that none of it has tried to contact us."
                                                  Calvin (Bill Waterson)
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: How to use 'return' in c?
Date: 14 Nov 92 01:36:56 GMT
Organization: negligable

In article <1992Nov7.122126.24409@druid.uucp> darcy@druid.uucp (D'Arcy J.M. Cain) writes:
>allebrandi@ipact.com writes:
>>The best thing to do is to use manifest constants to implicitly document
>>the value you are returning. For example, return TRUE or FALSE not 1 or
>>0 for a boolean function return.
>
>Whenever I see TRUE and FALSE in code I am maintaining I remove the
>#defines.  If they are defined, they should never be anything but
>TRUE = 1 and FALSE = 0.  Anything else is confusing and misleading.
>Given this why force the maintainer to go searching for the definitions
>to make sure that they are what they should never be anything but?
>This isn't as bad as #defining SEVEN as 7 but it is in the same category
>I think.

Wait a sec.... are you saying that if I have

	setFlagValue(TRUE);

somewhere you come along and change it to:

	setFlagValue(1);

??????

You consider that this is easier to maintain?????

It removes the intent behind the value!  "TRUE" shows intent to
use a boolean type (which does not exist in C), and that the
function is expecting a truth value of some sort.  Using "1"
is misleading in that the next person to come along only knows
that this function accepted some integer value without any
clue that it was primarly a truth value.

If I misunderstood your statement:
    "Whenever I see TRUE and FALSE in code I am maintaining 
    I remove the #defines"

I apologize for this post.  But to me the statement is a bit
unclear in it's intent. :)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Blasting, bursting, billowing forth with	|
the power of ten billion butterfly sneezes,	|	-Richard Hartman	
Man, with his flaming fire,			|	hartman@uLogic.COM
has conquered the wayword breezes.		|
Newsgroups: comp.lang.c
From: vasco@jessica.bvl.pt (Antonio Vasconcelos)
Subject: Re: EBCDIC to ASCII Conversion
Reply-To: vasco@jessica.bvl.pt (Antonio Vasconcelos)
Organization: Bolsa de Valores de Lisboa 
Date: Mon, 9 Nov 1992 18:48:43 GMT

 
>Does anyone know of a good way to convert EBCDIC characters to ASCII?
>I have the unfortunate need to transfer binary files from an IBM mainframe
>to our UNIX machines.

Try to use the 'dd' tool

	dd if=ebcdic_file of=ascii_file conv=ascii

However this MAY not work for you, take a look at your manual and check
what they say about the dd options 'ascii', 'ebcdic', 'block' and 'cbs'.
If you don't set the cbs parameter you should have a byte-to-byte conversion.

regards,

|/asco

Newsgroups: comp.lang.c
From: gregb@murphy.com (Greg Banschbach (Unigroup of New York))
Subject: Memory functions  -  memcpy & memmove
Organization: Murphy & Durieu, New York, NY
Date: Fri, 6 Nov 1992 13:50:58 GMT



	Dear fellow programmers,
	
		I am in the process of porting a program from MS-DOS to
	UNIX.   The program is a database program.   It calls "memmove"
	which is not available under  Unix Sys5 rel 2.   I substituted
	memcpy,  in order to get it to compile.   Now I discovered that
	what appears to be happening is that I am getting DUPLICATE 
	records in the INDEX file - probably when the b-tree is moving
	nodes around.    I still have to make sure that there are not
	any other problems, but I don't recall modifying any other parts
	of the code.  

		Has anyone written a function which would exactly mimic
	memmove ?   My  C book says that they are not EXACTLY the same 
	functions.     


			Thanks very much, 


			Greg  ( gregb@murphy.com ) 

	P.S.  Please respond by E-Mail.   Unless you think someone else
	      will benefit - but mail me anyway.



	
Xref: sparky comp.lang.c:16096 alt.cd-rom:4331
From: rab@sprite.berkeley.edu (Robert A. Bruce)
Newsgroups: comp.lang.c,alt.cd-rom
Subject: CUG Library CDROM free for contributors
Date: 6 Nov 1992 20:06:39 GMT
Organization: University of California, Berkeley
NNTP-Posting-Host: jaywalk.berkeley.edu

I forgot to mention this in my previous post, but just like all
other CD-ROMs, the CUG Library CD-ROM  is available for free to
anyone who has contributed any software to the C Users' Group.

If you have anything in the CUG Library, please send me the
volume number and filename, and I will send you a free CD.
If you are not sure if you have anything in the Library, you
can download the capsule descriptions of each file from
cdrom.com:/pub/cdroms/cug/capsule.txt and grep for your name.

	-bob
From: jkut@diku.dk (Jonatan Kutchinsky)
Newsgroups: comp.lang.c
Subject: Typedefing builtin... thanks.
Date: 9 Nov 92 15:04:14 GMT
Organization: Department of Computer Science, U of Copenhagen

I posted a question at comp.std.c about the justification of typedefing built
in datatypes for data abstraction reasons. I now know that a question like
that belongs in this newsgroup, and not in comp.std.c.

I just want to thank for all the good replies (13) i got, and give a short
summary:

People generally tended to agree with me on the use of the names BYTE, WORD,
and LWORD to represent unsigned 8, 16, and 32 bit variables in my simulation
of a Motorola 68000 processor. Some even proposed the use of special 
functions or macros for calculations, conversions to builtin types, and for
I/O. We are going to use this in our computer science project.

One stated that in his ideal program, builtin types were never used, and
names like f.x. Counter, and BigCounter would represent int and perhaps long,
depending on the machine used.

The major arguments used to justify these techniques were about portability.
A program is easier to port, when you can change some typedefs in a header
file, instead of changing a lot of ints to longs all over the code.

Once more i want to thank. The replies have been very useful.

*****************************************************************************
        Jonatan Kutchinsky, Copenhagen, Denmark. E-mail: jkut@diku.dk
*****************************************************************************
From: Jeff.Tomich@f380.n3603.z1.FIDONET.ORG (Jeff Tomich)
Newsgroups: comp.lang.c
Subject: NEED TO 'C'
Date: Fri, 06 Nov 92 08:38:56 PDT
Organization: FidoNet node 1:3603/380

Hello Marc!

05 Nov 92, Marc Poole writes to All:

 MP> @UFGATE newsin 1.27
 MP> From: fhi0055@hq.dla.mil (Marc Poole)
 MP> Date: 4 Nov 92 12:00:09 GMT
 MP> Organization: HQ Defense Logistics Agency/DASC, Cameron Station, VA
 MP> Message-ID: <944@hq.dla.mil>
 MP> Newsgroups: comp.lang.c,comp.lang.c++,comp.misc


 MP>  In a course study of the language turbo 'c', it was suggested that
 MP>  students should pick up a copy of THE C PROGRAMMING LANGUAGE 2ND
 MP>  EDITION - ANSI C, by Dennis Ritchie and Brian Kernigan.  Unfortunately
 MP>  throughout my search I am unable to find it anywhere.

 MP>  Can anybody tell me where this book can be ordered from or who might
 MP>  carry a copy?

I have picked up my copy at Walden's Bookstore or you can you get it at BDalton's Bookstore. Either carries it, if they do not have it they will order it. You can find those bookstore at any Mall.

Jeff

--  
Internet: Jeff.Tomich@f380.n3603.z1.FIDONET.ORG
UUCP:     ...!myrddin!tct!mechanic!380!Jeff.Tomich
Note: Mechanic is a free gateway between USENET & FIdonet.
      For information write to chief@mechanic.fidonet.org

Newsgroups: comp.lang.c