HDTenEightyP/NetNews huggingface dataset:
From: kimball@stsci.edu (Timothy Kimball)
Subject: Re: C if else statements HELP
Organization: Space Telescope Science Institute
X-Newsreader: TIN [version 1.1 PL6]
Date: Fri, 8 Jan 1993 17:47:06 GMT

Christopher M Toth (ctoth@magnus.acs.ohio-state.edu) wrote:
: 	Hi! I just started learning C and have run into problems with
: 'if' and'else' statements. I have a program that I am *trying* to write. The
: basic format is:
: 
: 	printf ("which do you choose?");
: 	scanf("%d", &n);
: 	choice#1
: 	choice#2
: 	choice#3
: 	choice#4
: 
: 	if choice #1
: 		printf.....
: 	if choice #2
: 		printf.....
: 	if choice #3
: 		printf.....
: 	if choice #4
: 		printf.....
: 
: 	I want the program to goto the approiate section when the user
: inputs either 1,2,3,or 4.

Do you want to _goto_ the appropriate section of the program,
or do you want to execute the appropriate lines?
Gotos are possible in C, but discouraged for anything but
serious error handling, and even then not without some work.

If this is your main(), then try something like this:

	printf ("which do you choose?");
	scanf("%d", &n);

	if (n == 1)
		printf(...);
	else if (n == 2)
		printf(...);
	else if (n == 3)
		printf(...);
	else if (n == 4)
		printf(...);

If you want to do more than one thing for each option,
then use blocks:

	if (n == 1) {
		printf(...);
		printf(...);
	} else if (n == 2) {
		printf(...);
		printf(...);
	} else if (n == 3) {
		printf(...);
		printf(...);
	} else if (n == 4) {
		printf(...);
		printf(...);
	}

Hope this helps some. -- tdk
From: gm08@fg30.rz.uni-karlsruhe.de (Steffani)
Newsgroups: comp.lang.c
Subject: ints and overflow
Date: 6 Jan 1993 16:06:08 GMT
Organization: University of Karlsruhe, Germany
Reply-To: gm08@rz.uni-karlsruhe.de
NNTP-Posting-Host: fg30.rz.uni-karlsruhe.de

these days we had a discussion what happens if you increment an
uninitialized integer. some ppl ment that there will be an error
because of an overflow. i do not aggree. 
my problem is: can i be shure dealing with integers that all
additions and subtractions will work modulo 2**(n+1) - 1 or
can be a problem of overflow causing an interrupt or trap.

hans friedrich steffani
From: steve@dbaccess.com (Steve Suttles)
Newsgroups: comp.lang.c
Subject: Re: readable code
Date: 8 Jan 93 04:19:32 GMT
Organization: Cross Access Corp., Santa Clara, CA
X-Newsreader: Tin 1.1 PL4

rorschak@daimi.aau.dk (Jesper Lauridsen) writes:
: murphy@npri6.npri.com (David P. Murphy) writes:
: 
: >>So the question of whether "x = x + 1" or "x += 1" is more "readable" is
: >>really a moot point.
: >>
: >>timk@world.std.com (Tim King)
: 
: >	"++x" is more readable.  [down!  down!  bad lurker! (whack) (whack)]
: 
: I prefer "x++" myself.

There are cases where "x -= -1" actually makes more sense...

...but there are those who would say that the best form is
"strBuffDesc.sLen -= TOKENSIZE".  Then again...

sas   (not to be consumed without adequate supply of chlorides)
-- 
Steve Suttles                Internet:  steve@dbaccess.com      Dr. DCL is IN!
CROSS ACCESS Corporation     UUCP: {uunet,sgiblab}!troi!steve  Yo speako TECO!
2900 Gordon Ave, Suite 100   fax: (408) 735-0328              Talk data to me!
Santa Clara, CA 95051-0718   vox: (408) 735-7545   HA! It's under 4 lines NOW!
Newsgroups: comp.lang.c
From: rene@hamel.uucp (Rene Mueller)
Subject: Re: Exact-sized types (was Re: Typedefing builtin... thanks.)
Organization: Free University of Berlin, Germany
Date: Wed, 6 Jan 1993 18:50:43 GMT

In article <84931@ut-emx.uucp>, jamshid@ut-emx.uucp (Jamshid Afshar) writes:
|> In article <1992Nov30.204147.7955@cimage.com> ejd@cimage.com (Ed Driscoll) writes:
|> |The typedefs I proposed
|> |would all specify size in bits, either exactly or at least that many bits.
|> |Using your example, there might be an at-least-18-bits type and an
|> |exactly-18-bits type (both with variations for signed and unsigned, I 
|> |suppose).  So there'd be no way to get confused about how many bits you
|> |were getting unless the typedefs themselves were incorrect.
|> 
|> I don't understand the purpose of the "at-least-N-bits" types.  C
|> already has those -- char (>=8), short (>=16), int (>=16), and long
|> (>=32).  What does your extra level of indirection buy you?
You are'nt correct:
int is as long as a single machine word on the machine (on some machines this means 12bit), on this machines also a short is 12bit long and a long is 24bits long...
The same is with characters
Some compilers will give you only the original ASCII-Characterset and a char-value with this machines is 7bit long, all other bits stored in memory for this value will be ignored...

	rene@math.fu-berlin.de
Xref: sparky comp.lang.c:19385 comp.os.vms:20540
From: harvey@indyvax.iupui.edu
Newsgroups: comp.lang.c,comp.os.vms
Subject: Re: Using C to read Fortran Files
Date: 7 Jan 93 18:44:38 -0500
Followup-To: comp.os.vms
Organization: Indiana University-Purdue University at Indianapolis

In article <C0GHCC.Cwp@ccu.umanitoba.ca>, kaarts@ccu.umanitoba.ca (Kenneth John Aarts) writes:
> In <C0G1rw.81L@ccu.umanitoba.ca> kaarts@ccu.umanitoba.ca (Kenneth John Aarts) writes:
>
>>I have a fortran program that does essentially
>
>>	open(unit=1,"test",status='new')
>>	write(1,10) 'cArt'
>>10	format(a4)
>>	end
>
>>and then a C program that reads it:
>
>>	int d1,d2,d3,d4,d5;
>>	FILE *fp;
>>	fp=fopen("test","r");
>>	fscanf(fp,"%c%c%c%c%c",&d1,&d2,&d3,&d4,&d5);
>>	printf("%d %d %d %d %d\n",d1,d2,d3,d4,d5);
>
>>The output of the C program is:
>
>>  10  65  114  116   13
>
>>  LF  A    r   t    CR
>
>>However, a fortran program reading the test program does see cArt.
>
> A little more information:
>
> This is all done on VMS.  The fortran created file has a 'fortran carriage
> control' record attribute.
>
> I do not have the option of rewriting the fortran code to add carriage
> control to the format statement.
>
> I need a way to convince VMS not to interpret the file before sending it's
> contents to the C program.

VMS isn't, RMS is.

> Thanks again,
>
> Ken

If you can't change either program, and your C program must be able to see
the actual FORTRAN carraige control characters, you can use something like
Joe Meadow's FILE utility to clear FORTRAN carriage control record attribute
in the file's header.  Then the out-of-band data (the actual FORTRAN carriage-
control characters) will be read as part of the record data.

Since this question has nothing at all to do with Unix, followups have been
directed to comp.os.vms ONLY...
--
James Harvey    IUPUI OIT Technical Support/Networks
harvey@iupui.edu  harvey@indiana.edu  uucp:iugate!harvey  bitnet:harvey@indyvax
Newsgroups: comp.lang.c
From: jbrad@cc.gatech.edu (John L. Bradberry)
Subject: Re: Conversion of BASIC code to "C"
Reply-To: jbrad@cc.gatech.edu (John L. Bradberry)
Organization: College of Computing, Georgia Tech
Date: Mon, 11 Jan 1993 17:40:55 GMT

In article <1993Jan10.131651.1@csbina.csubak.edu> camp5@csbina.csubak.edu writes:
>In article <1993Jan8.183821.20711@adobe.com>, (Scott Sivi) writes:
>> Does there exist a method or application by which BASIC files can be
>> converted 
>> to "C".
>You probably couldn't even do it by hand unless the BASIC program was 
>completely flowed and never used a GOTO! The way BASIC programmers spaghetti-
>code programs, I doubt it's possible. (I'm assuming you won't use goto in C.
>I wouldn't.)

Hmmm...I think a better answer here is it depends on who's BASIC and what
version! There are versions of HP BASIC and Microsoft BASIC that can be hand
converted (assuming relatively short - less than 100 lines or so) relatively
easily. Longer programs depend greatly on the skill of the programmer (I know
what some of you may be thinking - If he/she is skilled, why are they...).
This is also assuming that the language constructs used have a C equivalent
representation...

Unfortunately, much of BASIC code tends to be of the "throw away" variety. That
is, a test program or a program written by someone new to programming. In     
cases where the code is used for simple device drivers (HP BASIC) or where
there is lots of well structured code (yes, it can be done in some dialects
of BASIC!) there is stil the problem with statements that may be more trouble
to translate than its worth...mabye.


John L. Bradberry        |Georgia Tech Research Inst|001100110011001100110011
Scientific Concepts Inc. |Microwaves and Antenna Lab|Int : gt4512c@prism
1033 Franklin Rd. #11-295|404 528-5325 (GTRI)       |GTRI:jbrad@matd.gatech.
Marietta, Ga. 30067      |404 438-4181 (SCI)        |'...is this thing on..?'   
Newsgroups: comp.lang.c,comp.lang.c++
From: rfries@sceng.ub.com (Robert Fries)
Subject: Re: Dynamic Mem Help
Organization: Ungermann Bass
Date: Fri, 8 Jan 1993 21:45:34 GMT

In article <1993Jan8.205809.7661@klaava.Helsinki.FI> wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:

>rfries@sceng.ub.com (Robert Fries) writes:
>>You'll have to use an explicit cast of this value to 
>>assign it to a variable of type 'char *', e.g.:
>>
>>      str = (char *)calloc(10, sizeof(char));

>This is required in C++ only, not in ANSI C.

>In ANSI C no casts are needed when assigning a "void *" to a pointer
>to any data type (not including pointers to functions), or the other
>way around.

>--
>Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
>   MS-DOS, you can't live with it, you can live without it.

Oops, you're absolutely right.

Robert

//////////////////////////////////////////////////////////////////////////
Robert Fries
Ungermann-Bass Inc.

DISCLAIMER:
    Opinions contained herein are my own, and are not necessarily those
    of Ungermann-Bass.
//////////////////////////////////////////////////////////////////////////
From: sja@snakemail.hut.fi (Sakari Jalovaara)
Newsgroups: comp.lang.c
Subject: Re: Is that ansi ?
Date: 9 Jan 93 17:17:48 GMT
Organization: Helsinki University of Technology, Finland


>> [pointer to function isn't guaranteed to be castable to void*]

> : I'm afraid it's true, and one of the most serious faults of ANSI C.
> And a very good reason for it too. As I emailed to Daniel, some systems require
> more than an instruction pointer to reference a function.

Indeed, for example, on an IBM RISC System/6000 function pointers SORT OF
are 8 (or 12?) bytes.  A function pointer requires a pointer to the first
instruction and extra space for the dynamic run-time linker.

BUT in reality, on a System/6000   sizeof(int (*)(void) == 4.

Here is how it is done:

For every function a programmer defines in a C file, the compiler adds an
extra record like

    __INDIRECT_main:	.long	_main	# This is the address of the code
			.long	0	# This is for the linker
			.long	0	# As is this

When an address of a function is passed around in C, the __INDIRECT_main
address is used - a perfectly ordinary 4-byte pointer.  When a function
is called via pointer, the compiler uses code that digs the code address
(_main) via a double dereferencing and jumps there.

(If you insist on putting function pointers in void pointers you can
even emulate this trick manually -- hint: pointer-to-pointer-to-function
is guaranteed to fit in void*.)

I can think of two reasons why the C standard doesn't require that
function pointers can be cast to void pointers and back:

	1) The committee didn't happen to think of the above trick.

	2) The committee wanted to preserve existing compilers and
	   linkers on systems whose designers didn't happen to
	   think of the above trick.

Whether either reason is a good one or whether this is a "serious
fault of ANSI C" can be discussed 'til the pigs come flying home.
									++sja
Newsgroups: comp.lang.c
From: blume@kastle.Princeton.EDU (Matthias Blume)
Subject: Re: Pointer math (was Re: adding strings together)
Reply-To: blume@kastle.Princeton.EDU (Matthias Blume)
Organization: Dept. of Computer Science, Princeton University
Date: Tue, 5 Jan 1993 17:32:45 GMT

In article <C0E3Js.KIG@ocsmd.ocs.com>, ted@ocsmd.ocs.com (Ted Scott) writes:
|> Benjamin Ketcham (bketcham@stein.u.washington.edu) wrote:
|> : It's illegal to perform addition on pointers. 
|> 
|> 'Tisit?  consider:
|> 
|> char *end;
|> char buffer_stuff[128];
|> 
|> for(end = buffer_stuff + 128;(end > buffer_stuff && *end == ' ');end--) 
|>          ;  /* null loop body */                     ^^^^^^^^^^
|>                                          better to use some index func. here
|> 
|> Looks like addition and subtraction to me :-0
|> 
|> : That's one of the things I like about C.  It doesn't let you "just"
|> : add two strings together, without realizing what you are doing.
|> 
|> I contend that C will let you do alot without realizing what you're
|> doing. You can add two string pointers together, just don't expect the 
|> result to be a concatenated string.
|> 
|> --
|> 
|> -Ted Scott          
|> tscott@ocsmd.ocs.com           I was told that I'm a P.C. person:
|> (301) 601-2252                               Politically Challenged,
that is.

That's what I like: people who have deep knowledge and a full understanding
of what they are posting... :-(

-Matthias
From: sgg2@robin.cs.uofs.edu (Sudhir G Gajre)
Newsgroups: comp.lang.c
Subject: Help to learn C
Keywords: Learn C
Date: 6 Jan 93 20:40:53 GMT
Organization: Department of Computing Sciences

I would like to start learning C.  I have absolutely no previous experience with C.  Can anyone please suggest me the best way to start.  Also if there exists any FTP site with good examples of C I would appreciate if anyone can tell me its location.
Thank you,
Sudhir.
From: jrh3870@tamsun.tamu.edu (John R Harper)
Newsgroups: comp.lang.c
Subject: HELP! (with 2D dynamic allocation)
Date: 12 Jan 1993 10:59:15 -0600
Organization: Texas A&M University, College Station, TX
Distribution: world
NNTP-Posting-Host: tamsun.tamu.edu

  hello out there:

  (first, the disclaimer: i'm a novice in C, so please excuse any 
pinheadedness that follows.) 

  I have been using the following code snippet from the FAQ sheet to allocate a 2D array as follows:

   int **data;
   [...]
   data = (int **)malloc(ydim * sizeof(int));
   data[0] = (int *)malloc(xdim * ydim * sizeof(int));
   for(i = 1; i < ydim; i++){
      data[i] = data[0] + i * xdim;
   }

which seems to work like a charm, since it is followed by

   read(fp, &data[0][0], num_of_bytes);  /* this works ...     */

this (i think) just places a chunk of data (size num_of_bytes) into the contig-
uous dynamic array data[i][j]. 

  *now*, this array data[i][j] is passed to a function as follows:

   main(){
   [...]
   Function(data, xstart, ystart, xend, yend);  /* called within main() */
                                                /* declared in separate */
                                                /* module               */
   [...]
   }

then inside a _separate_ module:

   Function(data, x_start, y_start, x_end, y_end)   /* start separate module */
   unsigned short **data;
   short x_start, y_start, x_end, y_end; /* these let you process any      */
   {                                     /* subset of the array if need be */
   [...]
   mean = 0;
   for(i = x_start; i < x_end; i++){
      for(j = y_start; i < y_end; j++)
         mean = mean + *(data[i] + j);
   }
   [...]
   }

   then this is compiled (on an HP Apollo 400 series) as follows:

   % cc -c function.c 
   % cc -o main main.c function.o -lm 

   all the code above works on *square* arrays (tested up to 512 x 512). 
however, it crashes on *rectangular arrays* (for instance 128 x 21) with the
following error message:

   % segmentation fault (core dumped)   /* for the millionth time ... */ 

   i have placed a printf() inside the averaging loop above, telling me when
each element of *(data[i] + j) is accessed. the programs chugs along until it
gets up to data[50][0]. then the error occurs. 

   i seem to recall having this same problem in main() (with the read statement)until i made sure the allocated array was contiguous; but i could be mistaken. 

   any ideas? hopefully this has been coherent -- but if not, i'd be happy to
correspond via email if anyone is interested. any feedback would be *greatly*
appreciated. thanks!!

  j harper 

-- 
+-----------------------------------------------------------------------------+
| john harper               |   Department of Physics  Texas A & M University |
| jrh3870@tamsun.tamu.edu   |                    College Station, Texas 77843 |
+-----------------------------------------------------------------------------+
Newsgroups: comp.lang.c
From: dnl@convex.is.macsch.com (David Lombard)
Subject: Re: C code Layout
Organization: MacNeal-Schwendler Corp.
Date: Sat, 9 Jan 93 00:35:35 GMT

In article <C0II09.7FC@ulowell.ulowell.edu> vpham@cs.ulowell.edu (vinh) writes:
.. various excerpts...
>i think you guys are comparing apples an oranges here:
>emacs is an OS, vi is an editor, got that?

Along that line, I heard that when Cray ported emacs to Unicos, they decided
that booting Unicos from emacs was the best approach to use :-)

Regards,
DNL

                 MY_COMMENTS, MY_OPINIONS, NOBODY_ELSES.

David N. Lombard    The first thing we do,         The MacNeal-Schwendler Corp
dnl@macsch.com      Let's kill all the lawyers.    815 Colorado Blvd
(213) 259-4911      II Henry VI, IV.ii             Los Angeles, CA  90041
From: mcs@goblin.caltech.edu (Martin Shepherd)
Newsgroups: comp.lang.c
Subject: Re: Hex escaping in strings, (porting from gcc to cc)
Date: 6 Jan 1993 04:02:21 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: goblin.caltech.edu


In article 63463 in comp.lang.c dfuller@portal.hq.videocart.com says:
:chrisp@grace.cri.nz writes:
:: Hi,
::   I have a problem with porting from gcc to cc (on a sun sparc station)
:: 
::       puts("\x1b=");          /* set's the terminals keypad mode */
:: 
::  Works fine with gcc, the "\x1b" is interpreted as ascii 27, escape.  But
::  on cc it just prints "x1b=".
:: 
::  Is the hex code escape an ansii extension,  how else can I do it?, I would
::  rather avoid:
::       sprintf(tmp,"%c=",27);
:: 
::                               Thanks,  Chris.    chrisp@grv.grace.cri.nz
: 
:    You'll have to forgive me, i dont use gcc, and i dont keep track of
: the ANSI standard very well. What you have here is probably an extension 
: of gcc. The \ is used to escape n b t and a. Maybe others. It would appear
: that gcc added x as an escape for translating hex codes. What you need to
: do to make this work is to change the x1b to its octal value. This is 
: understood in ANSI C. 

Hexadecimal escape sequences were added in ANSI C - see pages 193-194
of K&RII for details. The reason that it didn't work in this case is
that SUN's cc is not ANSI.

: so puts("\x1b=")  ---->>>   puts("\033=")

This should work.

Martin Shepherd  (mcs@phobos.caltech.edu)
From: herring@netcom.com (John Herring)
Subject: Debugging with 2 terminals.  HELP!!!!!
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Distribution: usa
Date: Fri, 8 Jan 1993 21:37:10 GMT

Does anyone know of a debugger that will allow me to run the program on
one terminal and debug using the debugger in another terminal?

TIA

john
Newsgroups: comp.lang.c
From: steve@taumet.com (Steve Clamage)
Subject: Re: Problem with string processing.
Organization: TauMetric Corporation
Distribution: usa
Date: Wed, 6 Jan 1993 16:28:41 GMT

hartman@ulogic.UUCP (Richard M. Hartman) writes:

>Actually, on systems w/ block memory move supported at the
>CPU level, memcpy() can be implemented much more efficently.
>If there were a decent way of getting the string length w/o
>counting all the bytes then direct support for strcpy() could
>be done easily.  Are there any CPUs that have a single-instruction
>way of saying "find the next 0 byte & tell me how far it was from here"?

Of course there are, but this does not mean that such CPU's get a win
over CPU's which don't have the instruction.  One way or another, the
bytes in the string have to be examined.  (Metaphysics aside, that is.)

The question is whether you have one big complicated slow instruction,
or several small fast simple instructions, or something in between.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Newsgroups: comp.lang.c
From: alane@wozzle.linet.org (J. Alan Eldridge)
Newsgroups: comp.lang.c
Subject: Re: Help needed on Data Structure
Date: 10 Jan 93 16:06:00 GMT
Organization: Disorganization

ashafie@acsu.buffalo.edu (Afshin Shafie) writes:

> I want to write a program (database) in C that will run on SunOS 4.1.2.
> There will be about 4 fields for each entry and each field could be a 
> search field. There is about 10 MB of data, so speed is very important.
> The data will be mostly characters. So far, the few books that I was able 
> to get my hands on don't say much about implementation of databases.
> 
> If you could point me to a book or give me some hints/suggestions on 
> what data structure to use for a problem like this, I would really 
> apreciate it. 

Have you considered that there a load of public-domain, freeware, and
shareware database packages out there already, in C source code, that
you could just grab and use? Unless you are going for the learning
experience, I'd investigate that avenue and get on with the job.

(Well at least that's what I'd do.)

alane@wozzle.linet.org (J. Alan Eldridge)
Fido: The University of Walamaloo 1:272/38.473
From: watson@madvax.uwa.oz.au (David Watson)
Newsgroups: comp.lang.c
Subject: Re: Conversion of BASIC code to "C"
Date: 12 Jan 1993 23:20:19 GMT
Organization: Maths Dept UWA
Distribution: world
NNTP-Posting-Host: xanthorrhoea.maths.uwa.oz.au

In article <1993Jan12.003007.26709@organpipe.uug.arizona.edu>, dave@cs.arizona.edu (Dave Schaumann) writes:
|> In article <1993Jan10.131651.1@csbina.csubak.edu>, camp5@csbina writes:
|> >In article <1993Jan8.183821.20711@adobe.com>, (Scott Sivi) writes:
|> >> Does there exist a method or application by which BASIC files can be
|> >> converted 
|> >> to "C".

Yes, there is a conversion program call "The Gotoless Translator".
I don't know where to get it but I have seen the results from
converting a 30Kb BASIC program to C.  It looks weird but when
compiled it runs at about the same speed as the compiled BASIC.
It does eliminate all the gotos.
Does anybody know where it comes from? 

-- 
Dave Watson                          Internet: watson@maths.uwa.edu.au
Department of Mathematics            
The University of Western Australia               Tel: (61 9) 380 3359
Nedlands, WA 6009  Australia.                     FAX: (61 9) 380 1028
Newsgroups: comp.lang.c
From: rorschak@daimi.aau.dk (Jesper Lauridsen)
Subject: Re: readable code
Organization: Exile Government of Bramming
Date: Wed, 6 Jan 93 17:00:41 GMT

murphy@npri6.npri.com (David P. Murphy) writes:

>>So the question of whether "x = x + 1" or "x += 1" is more "readable" is
>>really a moot point.
>>
>>timk@world.std.com (Tim King)

>	"++x" is more readable.  [down!  down!  bad lurker! (whack) (whack)]

I prefer "x++" myself.
-- 
No News is Bad News
From: camp5@csbina.csubak.edu
Newsgroups: comp.lang.c
Subject: Re: Conversion of BASIC code to "C"
Date: 10 Jan 93 21:16:51 GMT
Followup-To: comp.lang.c
Organization: California State University, Bakersfield

In article <1993Jan8.183821.20711@adobe.com>, (Scott Sivi) writes:
> Does there exist a method or application by which BASIC files can be
> converted 
> to "C".
You probably couldn't even do it by hand unless the BASIC program was 
completely flowed and never used a GOTO! The way BASIC programmers spaghetti-
code programs, I doubt it's possible. (I'm assuming you won't use goto in C.
I wouldn't.)
From: jwh@cs.bham.ac.uk (James Hawtin)
Newsgroups: comp.lang.c
Subject: Re: How to read without echo.
Date: 4 Jan 93 21:26:26 GMT
Reply-To: jwh@cs.bham.ac.uk
Organization: School of Computer Science, The University of Birmingham, UK

What system do you want this for, PC, Sun 4? I have the UNIX solution of the echo
problem.  


			James
Newsgroups: comp.lang.c