HDTenEightyP/NetNews huggingface dataset:
From: throop@aurs01.UUCP (Wayne Throop)
Newsgroups: comp.lang.c,comp.sys.sun.misc
Subject: Re: sun cc optimization failure
Summary: deficient optimizer technology
Date: 3 Sep 92 19:12:20 GMT
Reply-To: throop@aurw44.aur.alcatel.com.UUCP (Wayne Throop)
Organization: Alcatel Network Systems, Raleigh NC

-   #include <stdio.h>
->> main() {
->>        int i,j,ax;
->>        ax = 0;
->>        for(i=0;i<3;i++){
->>                j = ax * i;
->>                puts("in for loop");
->>        }
-          return 0;
->> }
->> when compiled with cc (sun os 4.1 on sparc 1+), the
->> code runs thru the loop three times. when comiled with
->> the -O flag it only runs once. 
-> If you look at the assembler output of the compiler using the following

Out of curiosity, I ran this through the three compilers I had
available for the MIPS architecture (decstation) machine I have here.  
The two MIPS-based compilers (classic and ansi C) both optimized
the loop to be

        move    $16, $0
        la      $17, $$50
        li      $18, 3
  $32:
        move    $4, $17
        jal     puts
        addu    $16, $16, 1
        bne     $16, $18, $32

The gcc 1.39 mumble-whatever version I have made it

        move    $16,$0
  $L5:
        subu    $sp,$sp,16
        la      $4,$LC0
        jal     puts
        addu    $sp,$sp,16
        addu    $16,$16,1
        ble     $16,2,$L5 

In general, this older gcc does significantly more frame-and-stack
pointer twiddling, both in this loop and in the prolog and postlog
code and the like, compared to the MIPS-based compilers.  
(2.0 may do better.)

But the thing that struck me was, why didn't the optimizer just

        la      $4,$LABEL
        jal     puts
        jal     puts
        jal     puts

(or some variation on this theme) as it "should" have?  

( Maybe there are RISCish slot-filling considerations that prevent it... 
  but I really think the compilers just don't do simple loop unrolling,
  even when they've already demolished the innards of the loop anyhows. )

Just another of the many things that make me go "Hmmmmmm."

Wayne Throop       ...!mcnc!aurgate!throop
Newsgroups: comp.lang.c,comp.lang.c++
From: zzang@whale.uucp (Zhuo Zang[~{j0WA~}])
Newsgroups: comp.lang.c
Subject: Kwik escape from recursive loop, Possible?
Date: 29 Aug 92 22:19:41 GMT
Distribution: usa
Organization: University of Florida

Hello,
I am writing a program.
In the program, I use a 'while (c!=EOF)' statement to write char.
I also have a recursive call to get input char in the program,
this caused problem. the recursive call piles
up a huge stack when the c finally reaches the EOF;
then it returns one by one, so my output file
ended with many(48 in one eg.) EOF's (the 0xff in DOS).

my question is: is it possible to escape from
the loop immediately without returning the garbages 
once c reaches the EOF ?

Many thanks in advance !

-- 
Zhuo Zang[~{j0WA~}]

University of Florida            Email: zzang@stat.ufl.edu
Newsgroups: comp.lang.c,comp.lang.c++,comp.binaries.ibm.pc.d
From: kjb@cgl.citri.edu.au (Kendall Bennett)
Subject: Contacting Al Stevens...
Organization: RMIT Advanced Computer Graphics Centre, CITRI, Melbourne
Date: 28 Aug 92 14:16:49 GMT

Does anyone know how to contact Al Stevens from DDJ over the internet?
He wrote the DFLAT windowing system for MS DOS, and I would like to 
talk to him...

+------------------------------------------+-------------------------------+
| Kendall Bennett,                         | Internet:                     |
| Advanced Computer Graphics Centre,       | kjb@citri.edu.au              |
| Royal Melbourne Institute of Technology, | rcskb@minyos.xx.rmit.oz.au    |
| Victoria, AUSTRALIA.                     |                               | 
+------------------------------------------+-------------------------------+
| CoSysop (Bossman), PC Connection Australia:               +61 3 688 0909 |
+--------------------------------------------------------------------------+
Newsgroups: comp.lang.c,comp.lang.pascal
From: leonard@qiclab.scn.rain.com (Leonard Erickson)
Subject: Re: Pascall Typed Files
Reply-To: 70465.203@compuserve.com
Organization: SCN Research/Qic Laboratories of Tigard, Oregon.
Date: Tue, 1 Sep 1992 03:13:44 GMT

tsv@dbrus.Unify.Com (Tim Vannaman) writes:

>OK, since I can't put pascal obj's into my c code, how can I read a typed file
>created by pascal into my C program?  (Turbo C & Pascal)

>ex.
>  In pascal :

>  Type
>     scuz = record
>	      Player string[25];
>	      Age    integer;
>	      Money   float;
>	    end;
>     
>  Var 
>    fil : File of Scuz;


>If I load the file full of data, how would I go about reading and re-writing it
>in C?  I tried getting a hex dump of the file, but it didn't make any sense.

The more recent TP manuals leave out a *lot* of needed info. (Or so I've
found from noting the number of times I've had to go back to my TP 5.5
manuals to answer a question)

The file is merely a bunch of records concatenated together.

The records are merely the component variables concatenated together.
There are no "seperators".

What probably threw you off is not knowing the structure of a TP string.
	string[n] : array[0..n] of char;
Element 0 is used to stored the length of the current contents of the string.
So in your structure, Player is stored as *26* bytes. The first byte tells
you how many of the following bytes are meaningful. The rest of the bytes are
junk.

To make things easier when troubleshooting, I've taken to doing a 
	FillChar(Scuz,sizeof(scuz),#0); 
to clear the record to all nulls before adding the data, and writing it
to disk. That way I don't have to look at all the junk in the unused
portion of the strings, and I can do compares using normal comparison
software.
-- 
Leonard Erickson		      leonard@qiclab.scn.rain.com
CIS: [70465,203]			 70465.203@compuserve.com
FIDO:   1:105/51	 Leonard.Erickson@f51.n105.z1.fidonet.org
(The CIS & Fido addresses are preferred)
Newsgroups: comp.lang.c
From: atbowler@thinkage.on.ca (Alan Bowler)
Subject: Re: Convert COBOL COMP-3 to double?
Organization: /etc/organization
Date: Mon, 31 Aug 1992 17:46:51 GMT

In article <1992Aug26.151021.4445@afs.com> jack@afs.com (Jack Brasch) writes:
>Could someone point me in the right direction or mail me a routine to  
>convert COBOL COMP-3 types to a double.
>

The starting point would be the Cobol programmer's guide for your
particular Cobol implementation.  Somewhere in there it should tell you
exactly what COMP-3 is for that Cobol implementation.  The starnadrds
only say that you can do arithemetic on comp-N items.  What the -N
produces on your hardware varies with every Cobol compiler.  It is not
unlikely that comp-N means different things to different compilers on
the SAME hardware.  (I have seen this several times.)  When you know
what the hardware is doing with comp-3 on this Cobol compiler, figuring
out how to convert to a C double should be straight forward.  At worse
you can move it to a DISPLAY item, and let the C code call strtod().
Newsgroups: comp.lang.c
From: aland@chaos.cs.brandeis.edu (Alan D.)
Subject: Re: Most difficult part of learning C?
Reply-To: aland@cs.brandeis.edu
Organization: As little as possible
Date: Wed, 26 Aug 1992 18:25:30 GMT

Ketan.Deshpande@bbs.oit.unc.edu (Ketan Deshpande) writes:

>In article <9208251159.AA04122@ult4> goldstei@cgi.com ("Morris Goldstein") writes:
>>I am conducting research for a little project concerning difficulties in
>>learning C and how to improve the teaching of C so as to circumvent these
>>problems.
>>
>>When learning C, what things did you find the most confussing/difficult to
>>understand?

>The most difficult thing for me was to understand that given a declaration
>like
> int a[10];

>both the following are correct:
>   a[6] =  ....;
>   6[a] = ....;

I understand that this is a difficult thing to understand, at first...
But is it really an integral part of C to understand this?  I can't
think of any situation in which I would need to know this...

	-=Alan
Newsgroups: comp.lang.c
From: jose@nosc.mil (Jose R. Vazquez Santana)
Subject: Random Number Generators
Keywords: random
Organization: Naval Ocean Systems Center, San Diego, CA
Distribution: usa
Date: Thu, 27 Aug 1992 18:19:31 GMT

Hi,

I'm working in a piece of software that need a random number
generator.  I have try the ones provided in SunOS 4.1.1(drand48,
lrand48, rand).  Lrand48 seem better than rand() but the 
numbers are not random enough no matter what the seed is.  I
cannot get drand48 to work right.  It always gave the same
numbers.  Does anybody have any experience with drand48?  If you
know or have a good random number generator, I'll be glad to
hear from you.  Please reply by e-mail.

Thanks.

***************************************************************
*                            *                                *
* Jose R. Vazquez            * Phone: (619)553-6337           *
* NRaD                       * Email:                         *
* Code 847                   *        DDN: jose@nosc.mil      *
* San Diego, CA  92152-5000  *        UUCP: sdcsvax!nosc!jose *
*                            *                                *
***************************************************************
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.lang.c
Subject: Re: Giles' Manual Mania (Was - Re: About the 'F' in RTFM)
Date: 3 Sep 92 21:46:51 GMT
Organization: CWI, Amsterdam

In article <1992Sep3.162038.28706@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
 > In article <QUANSTRO.92Sep2095812@lars.StOlaf.edu>, quanstro@lars.StOlaf.edu (goon) writes:
 > |> You are great at speaking in generalities. Which systems _have_ you
 > |> used? 
 > 
 > CDC's Scope was *much* easier to use.  Being a `vintage' system, it had
 > about the same capabilities as UNIX.
Eh?  What about the approximately flat file system, the inconsistency
between programs with respect to their argument handling?  Most new
users of INTERCOM (the interactive part of SCOPE, later of NOS/BE)
always had problems that using the following sequence of commands:
	FTN,I=INPUT1.
	LGO.
	FTN,I=INPUT2.
	LGO.
the first program is executed twice.
Also the times are countless that I wanted to save some file, which
I had not thought of earlier (normally files you created are lost
at the end of the job/session), there were two ways:
	SAVE,FILE,DW.
which always used the same cycle number (999) or:
	REWIND,FILE.
	REQUEST,NFILE,*PF.
	COPY,FILE,NFILE.
	CATALOG,NFILE,ID=DW.

About the inconsistency and the duplication of utility.  What is the
difference between:
	FETCH,FILE,DW.
and
	ATTACH,FILE,ID=DW.
and why is the ID parameter handled differently?
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland
dik@cwi.nl
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: C function declaration
Date: 1 Sep 92 22:39:45 GMT
Article-I.D.: ima.1992Sep01.223945.7413
Organization: Interactive Systems, Cambridge, MA 02138-5302

In article <1992Sep1.141107.1972@bernina.ethz.ch> stettbac@isibee3 (Juerg Stettbacher) writes:
>How would you call the C function:
>   void (*signal(int sig, void(*func)(int)))(int)

#include <signal.h>
#include <stdio.h>
sig_atomic_t volatile ouch = 0;
void handler(int signo) { ouch = 1; }
int main(void) {
    void (*oldhandler)(int);
    if ((oldhandler = signal(SIGINT, SIG_IGN)) != SIG_IGN) {
	(void)signal(SIGINT, handler);
    }
    while (!ouch) {
	printf("waiting...\n");
	sleep(5);
    }
    printf("signal received\n");
    (void)signal(SIGINT, oldhandler);
    return (0);
}

>And what does this prototype mean?

It means that |signal| is a function, whose first argument is an integer
(representing a signal number) and whose second argument and return value are
function pointers (representing the new handler for that signal, and the
previously established one, respectively).  The pointed-to functions have one
argument (representing the signal number), and no return value.

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: Help: problem codes
Date: 31 Aug 92 08:38:47 GMT
Organization: AND Software BV Rotterdam

In article <1992Aug31.003108.9782@uoft02.utoledo.edu> qding@uoft02.utoledo.edu writes:
|
|Hi, there.
|I have a C program (shown below) which shows error
|of >> Illegal structure operation in fuction sum. But I just
|do not understand what's wrong with it. Can some one help out of
|this please ?
|
|C codes ----
|
|typedef double tuple[4];
|
|typedef struct vector {
|	integer      dim; /* the dimension of the vector */
|	tuple        component; /* the array of components */
|} vector; /* the definition of type vector */
|
|/* function sum */
|vector sum(vector a, vector b)
|{
|   integer      i;
|   sum.dim = a.dim;
|   for (i = 1; i <= a.dim; i++)
|   sum.component[i] = a.component[i] + b.component[i];
|} /* function sum */

Welcome Pascalien! Welcome to the wonderful world of C! ;-)
No, seriously, I strongly suggest reading K&R2 before you start
coding in C. You've just done a basic translation from Pascal to C,
and things don't work that way. A few hints:

- non void functions (Pascal: non procedures) use the `return' statement
  to return a value to the caller.

- the name of a function is _not_ a left hand value.

- array offsets start at 0 in C, not at 1 as in Pascal.

- an integral number type is called `int', not `integer' as in Pascal.

Here's your function again, a bit rewritten:

vector sum(vector a, vector b)
{
   int    i;
   vector sum_val;

   sum_val.dim = a.dim;
   for (i = 0; i < a.dim; i++)
   sum_val.component[i] = a.component[i] + b.component[i];

   return sum_val;

} /* function sum */

Please do read a good text book (take K&R2), it'll save you a lot
of trouble. 

kind regards,

Jos aka jos@and.nl
From: aphaswan@cs1.uct.ac.za (AK PHASWANA)
Newsgroups: comp.lang.c
Subject: How can one make a dynamic array?
Date: 3 Sep 92 09:46:09 GMT
Organization: Computer Science Department, University of Cape Town


Hi

Most sorting procedures like bubble sort, bisection method, merge sort,
use arrays. The problem with arrays is that they are not dynamic.
Or is there any way of implementic sorting and searching procedures
without using arrays?
Newsgroups: comp.lang.c
From: chupchup@ferkel.ucsb.edu (Robert Earl)
Subject: Re: main()
Organization: (EVIL!)
Date: Thu, 3 Sep 1992 08:30:38 GMT

doug@tisdec.tis.tandy.com writes:


| Actually main() is defined as
|   int main(int argc, char **argv, char *envp);

(I'm assuming "char *envp" was a typo of "char **envp").  Not in ANSI
it isn't.  There's no such thing as "envp".  If your system refuses to
translate a program without the envp declaration, it's not
ANSI-conforming.

| Argc is the number of arguments on the command line, with the program
| name counting as one, argv is a pointer to an array of pointers to the
| arguments (program name is argv[0]), and envp is a pointer to array of
| pointers to the program's environment variables.  This last is very
| rarely used so you will usually see it prototyped with only 2 parameters.

It's very rarely used in UNIX, particularly, because the startup
routine stuffs envp in a global variable called "environ", probably so
main() doesn't have to do it all the time.  But "environ" doesn't
exist in ANSI only getenv() and putenv(), and this is comp.lang.c.  :-)

-- 
"If you've got a pig that likes jumping fences, | robert earl
you have to make its fence a lot higher all at  | rearl@ucsd.edu
once -- if you do it by increments, all you're  | rearl@piggy.ucsb.edu
doing is training a jumping pig." -Henry Spencer|
From: ajayshah@almaak.usc.edu (Ajay Shah)
Newsgroups: comp.lang.c
Subject: Re: Why should POINTERS be so damn hard to understand ?
Date: 26 Aug 1992 11:58:44 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: almaak.usc.edu

tony@nexus.yorku.ca (Anthony Wallis) writes:

>Jim Sullivan (sullivan@alw.nih.gov), in response to  
>> > When learning C, what things did you find the most
>> > confusing/difficult to understand?
>says
>> What else?... POINTERS!

>(This seems to be a common gripe from students subjected to that
> Blaise-ing insult known as "Pascal" too.)

On the contrary, I did a fortran --> basic --> pascal --> turbo pacal
--> awk --> C route.  I found that an Extremely crisp clarity
with Pascal pointers was a great asset in quickly jumping into
pointers with C.

Most pascal students don't have time enough in a first course to
really think about pointers.  I think that is the real problem, not
Pascal itself.  (I never did classes in programming, so I can't really
tell).

IMHO Pascal is still the best first teaching language I can see.
I would move on to C soon, but it's hard explaining C to someone
who has never written programs before.  If you have not laboured
writing x = x + 1; thousands of times, you won't appreciate
++x and x++.

        -ans.
-- 
Ajay Shah, (213)749-8133, ajayshah@usc.edu
Newsgroups: comp.lang.c,comp.unix.programmer,comp.sys.sun.misc
From: warren@orion.tsc.gtefsd.com (Hugh Warren)
Subject:  SunOS 4.1.2: Increasing per process file pointers
Organization: GTE-FSD in Chantilly, Virginia.
Date: Tue, 1 Sep 1992 21:48:28 GMT

How can you increase the number of open file pointers allowable
per process under SunOS 4.1.2?  I'm hitting a limit of 60 using
fopen() right now.  Thanks for any help...
		warren@orion.tsc.gtefsd.com
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: main()
Date: 2 Sep 92 08:39:29 GMT
Organization: University of Helsinki

cee1@ra.msstate.edu (Charles Evans) writes:
>Ok, I thought supposadly in ANSI C/C++ one was to declare main() as such:
>either:
>
>int main(void)
> or
>void main(void)

Only the first one is legal under ANSI C.  There is no ANSI C++ yet, as
far as I know.  I'm not going to be impressed if they legalize ``void
main'', but since C++ is ugly anyway, I'm not going to be heartbroken
either.  ``void main'' doesn't work for all C compilers, although it
unfortunately does work for many. 

>BC++ books say int main(void) but what is the benefit of 'return 0' at the
>end.. seems like wasted space.

It it NOT wasted space.  Each and every function (that returns at all)
needs to explicitly return some value, otherwise it will return garbage
value and cause your hair turn into worms.  This includes the main
function.  If you don't specify a return value for main, how is the
compiler going to know what value to return? And if you return random
values from main, the operating system (that called main to run your
program) is going to be very confused.  Some of us actually use the
return value of main to see whether a program worked or not. 

Of course, if you terminate your program with exit or abort, it will
never get to the end of main, so in that case there is no need to
include a return statement there.  In fact, as a stylistic issue, I
prefer to use ``exit(0)'' instead of ``return 0'' in my programs.  That
is purely personal opinion, of course. 

>Now in VERY new C++ books or VERY new C books, they usually have either
>
>int main()
>or void main()

C books that have ``void main'' are broken and are probably only useful
for heating purposes. 

>so what should i use

Use:	int main(void)

I have ignored the possibility to use command line arguments to main. 
If you want those, you use the declaration:

	int main(int argc, char **argv)

or the equivalent, but misleading (read the FAQ to learn more about
this; if your C books say void main I guess you can't trust those enough
to learn about pointers either):

	int main(int argc, char *argv[])

There are a couple of other legal versions as well, but they are only
variations of the above with some keywords dropped.  I don't encourage
them, unless you use Classic C (in that case you can say ``int main()''
instead of ``int main(void)'', as the latter doesn't work in Classic C).

--
Lars.Wirzenius@helsinki.fi	"shouldn't ``struct foo main'' be legal too?"
Newsgroups: comp.lang.c
From: behrenss@Informatik.TU-Muenchen.DE (Soenke Behrens)
Subject: Re: Order of execution...
Keywords: Umm, Uhh, Well, Daa, Gee
Organization: Technische Universitaet Muenchen, Germany
Date: Sun, 30 Aug 1992 17:40:34 GMT
Distribution: usa

linley@seas.ucla.edu (Bruce Linley) writes:

>This subroutine is supposed to convert a string to all lower case:
>int StripCase(textLine)
>char textLine[];
>{
>  register int index = 0;
>  
>  while ((textline[index++] = tolower(textLine[index])) != '\0');
>}
>The question is will it always work?

No. 

Better would be: 

for(;(textline[index] = tolower(textline[index])) != '\0';index++);
                                    ^
				    I assume you made a typo here and
				    there is no textLine.

BTW, this will only work for "printable" ASCII characters, so you are in
the dark if the text uses Umlaute or similar.

Yours
Soenke
-- 
===========================================================================
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: subodn@informix.com (Subodh Nijsure ( Su-bo-d Ni-j-su-ray ))
Newsgroups: comp.lang.c
Subject: Should C compiler flag error for this?
Date: 27 Aug 92 23:57:03 GMT
Organization: Informix Software, Inc.
Originator: subodn@godzilla

For the following program should a C compiler flag an error or a warning.

#include <stdio.h>
extern int i;
static int i=30;
main()
{
	printf("Value of i is %d\n",i);
}

-Subodh ( smn@netcom.com )
From: edrury@3cpu.rain.com (Ed Drury)
Newsgroups: comp.lang.c
Subject: Re: Most difficult part of learning C?
Date: 28 Aug 92 21:42:15 GMT
Reply-To: edrury@.UUCP (Ed Drury)
Organization: Garden Lane Software


 I guess I'm the only one who had this trouble learning C, but for
me personally, I could have received a lot more help with memory
management. In the previous languages I had experimented with, the
programmer was not allowed to handle dynamic memory management - at
least he certainly wasn't encouraged to. Suddenly, I'm able to make
spectacular crashes and real hard to find bugs by creating dangling
references. The information in K & R and my compiler manuals on
malloc, calloc, and free seemed straight forward. But in practice I
was dazed and confused. Now I was writing in a language which allowed
me to fiddle with things I didn't understand the theory behind.

 So , I guess what I'm saying is that in my case some assumptions
were made about where my level of understanding language implimentation
and computer theory were made. In my case, I was playing catch up
ball and couldn't appreciate C fully without this background. Doing
some extra home work in this reguard, doors opened, bells chimed and
I fell in love a second time with this language. And the second time
is more beautiful.

   Ed
-- 
   __
 /--   __/
(___, (_/rury@3cpu.rain.com
Newsgroups: comp.lang.c