HDTenEightyP/NetNews huggingface dataset:
From: rshouman@chpc.utexas.edu (Radey Shouman)
Subject: Re: Low level routines to do logical shifts
Keywords: lshft,rshft etc.
Organization: The University of Texas System - CHPC
Date: Sun, 23 Aug 92 20:29:12 GMT

In article <134179@lll-winken.LLNL.GOV> stevep@phoenix.ocf.llnl.gov (Steve J Patenaude) writes:

	[...]

>First, to do a <while> loop in Fortran 77, you must use the
>dreaded -gasp- GOTO!
>
>C FORTRAN FOR 'while (foo < finished) foo += incr;'
>1     IF (FOO .GE. FINISHED) GOTO 2
>      FOO = FOO + INCR
>      GOTO 1
>C END OF WHILE LOOP
>2   ...

A somewhat neater (one less statement label) way to do this is to use 
a fortran77 block if:

 1	IF (FOO .LT. FINISHED) THEN
          FOO = FOO + INCR
	  GOTO 1
 	ENDIF

Of course, for this particular example, a DO loop might well be preferable.





-- 
Radey Shouman					rshouman@chpc.utexas.edu
Newsgroups: comp.lang.fortran
From: jumper@garfield.catt.ncsu.edu (Michael Lanham)
Subject: Linking C modules into FORTRAN main; COMMON blocks & more
Organization: North Carolina State University
Date: Thu, 27 Aug 1992 23:22:07 GMT

I have an older FORTRAN program that I am trying to incrementally rewrite
using C.  How do I/Can I access common blocks from inside the C code?  If it
is possible could someone fill me in?


He who will not reason, is a bigot; he who cannot is a fool;
and he who dares not is a slave.      --- Sir William Drummond

Michael Lanham       mjlanham@eos.ncsu.edu   &  jumper@catt.ncsu.edu
From: mlubran@engws8.ic.sunysb.edu
Newsgroups: comp.lang.fortran
Subject: Upgrading obsolete code
Keywords: FORTRAN,DECODE,UPGRADE,HOLLERITH
Date: 4 Sep 92 20:29:58 GMT
Article-I.D.: sbcs.1992Sep4.202958.29575
Organization: State University of New York at Stony Brook
Originator: mlubran@engws8.ic.sunysb.edu


I have to find a way to simulate the effect of the DECODE statement,
because MS-FORTRAN 5.0 does not seem to support it. A sample of what
I need would resemble something like this...



*      MAIN
       IER=1
       CALL TEST(IER,6HMYSUB )
       END
*******************************************
       SUBROUTINE TEST(IER,NAME)

       INTEGER IER,NAME(1)
       INTEGER STRING(6)

       CALL UNPACK(NAME,6,STRING)

       PRINT *,'ERROR #',IER,'DETECTED IN ROUTINE ',STRING

       RETURN
       END
********************************************
       SUBROUTINE UNPACK(NAME,I,NAM)

       INTEGER I,NAME(1),NAM(1)

* NOTE: MAX CHARS IS 129

       DECODE (I,150,NAME) (NAM(J),J=1,I)
150    FORMAT (129A1)

       RETURN
       END



THE RESULT SHOULD BE:

ERROR # 1 DETECTED IN ROUTINE MYSUB




VMS AND UNIX LOVE THIS KIND OF STUFF, BUT MY PC
SEEMS TO REGARD THIS AS COMPLETELY OBSOLETE!!!

Is there a way to make UNPACK work without the DECODE??
If not, can anyone suggest a compiler for a PC which
can handle this?? (preferably by anonymous ftp)

BTW,   I would re-write this to use CHARACTER variables,
       but UNPACK is called by far too many other routines

Any and all assisstance will be appreciated.


M. Lubrano
Newsgroups: comp.lang.fortran
From: gerardo@ferris.cray.com (Gerardo Cisneros)
Subject: Re: CRAY-YMP language constants != machine constants.
Organization: Cray Research, Inc.
Date: 1 Sep 92 10:29:55 CDT

In article <392@yak.COM> tpd6908@yak.COM (Tom Dickens) writes:
>Just thought I would inject some personal experience on a Y-MP (Unicos 6.1).
>I have an application with mixed C and FORTRAN.  I needed some constants
>such as min/max float values and found them in a C include file.  I then
>copied these numbers into a FORTRAN routine, compiled, and got out-of-range
>compiler errors.  Doing the same thing in C worked OK.
>
>I still do not have an explination from Cray why this happened.

I tried e-mailing Mr. Dickens, but the message bounced:
   ----- Transcript of session follows -----
550 <tpd6908@yak.com>... Host unknown

Could you e-mail me the shortest possible Fortran and C programs exhibiting
this behavior?

I'm interested in knowing what is going on.
-- 
Gerardo Cisneros		|Cray Research de M'exico, S.A. de C.V.
gerardo.cisneros@cray.com	|Camino a Sta. Teresa 480-A #302
(+52+5)622-8584 		|14020 Tlalpan, D.F., MEXICO
 Anything I said sound like an opinion? Then it's no one's but my own.
Xref: sparky comp.lang.fortran:3263 comp.unix.cray:253
From: rsherme@diamond.nswc.navy.mil (Russel Shermer (R43))
Newsgroups: comp.lang.fortran,comp.unix.cray
Subject: Re: CRAY-YMP single precision machine constants.
Date: 28 Aug 92 16:00:58 GMT
Organization: NAVSWC DD White Oak Det.


In article <1992Aug27.160828.18574@tamsun.tamu.edu>, ssp2537@tamsun.tamu.edu (Satya Srinivas Padavala      ) writes:
|> Hi Folks,
|> 
|>      I am wondering if any knowledgeable soul could help me with the following 
|> problem. I have been using in my code, BLAS (Basic Linear Algebra Subprograms),
|>  which are routines called by public domain math packages such as LINPACK, 
|> EISPACK etc. I have recently started working on a CRAY-YMP and am need of the 
|> following machine constants for single precision for that machine. 
|> 
|>  1) Smallest positive magintude
|>  2) Largest positive magnitude
|>  3) Smallest relative spacing
|>  4) Largest relative spacing
|> 
|>  I would appreciate your help if you can point me where I can find these
|> values.
|> 
|> Thanks,
|> Satya Padavala
|> ssp2537@tamsun.tamu.edu 

I'm on a Cray-2 but, you should be able to find the max and min info
in /usr/include in the files:

limits.h
values.h
float.h

I didn't see any spacing information.  There are very simple
algorithms for computing the machine epsilon.  Basically,
you compute the smallest number larger than 1 that the machine
can distinguish.

Hope this helps.

	---Russ
From: rgonzal@gandalf.rutgers.edu (Ralph Gonzalez)
Newsgroups: comp.lang.fortran
Subject: Is F90 coming to Suns?
Keywords: f90
Date: 1 Sep 92 16:47:57 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


I'm teaching a Fortran course on Sun Sparcs this Fall. In the past
I've slipped a little material on F90 into the course at the end. Does
anyone know whether F90 will be available for these machines anytime
soon? (It's 1992, you know!)

Sun Fortran has a lot of extensions, but they're in a different vein
from those in F90 -- particularly F90's MODULE structures.

Sorry if this is a FAQ. I'm trying to reduce my netnews time so I'm
not subscribed to this group. Please email responses and I'll
summarize if there's interest.

Thanks,
Ralph Gonzalez
rgonzal@elbereth.rutgers.edu
-- 
Ralph Gonzalez, Computer Science, Rutgers Univ., Camden, NJ
Phone: (609) 757-6122; Internet: rgonzal@elbereth.rutgers.edu
--
Newsgroups: comp.lang.c
From: fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald)
Subject: deref NULL but no core dump on aix 3.1 ??
Summary: wtf?
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Mon, 31 Aug 1992 05:48:54 GMT

Why does this incorrect not dump core on an rs6000 running aix3.1 (but
it does on a sun3).

Assume that the HOME environment variable is not set.  getenv returns
the NULL pointer.

Brian

#include <stdio.h>
char *getenv();

main()
{
    char           *home;

    home = getenv("HOME");
    if (!home)
	fprintf(stderr, "Warning: The HOME environment variable is not set\n");
    /*else*/ if (*home == '\0')
	fprintf(stderr, "Warning: The HOME environment variable is null\n");
}

(btw, I fixed the code by adding "else", where shown.)
Newsgroups: comp.lang.c
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: main()
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 2 Sep 1992 22:18:08 GMT

harrison@lclark.edu (Mark Harrison) writes:

>In my programs, I use 'void main()' and never had any problems doing so. 
>These are written with Turbo C/C++ 3.0, so I don't know about any others.

Well, I guess you were just lucky then.
Try compiling with "-A" ("Ansi" - disable extensions) and "-P" (Compile as
a C++ program). With these options, Turbo C/C++ 1.0 gives me a compile error.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: wkaufman@us.oracle.com (William Kaufman)
Newsgroups: comp.lang.c
Subject: Re: Why should POINTERS be so damn hard to understand ?
Date: 4 Sep 92 02:38:23 GMT
Organization: Oracle Corporation, Redwood Shores CA
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

In article <Btx3II.Fyn@multisys.com> rot@multisys.com (Republic of Taiwan) writes:
] =In article <1992Aug27.135946.6622@infonode.ingr.com> henders@infonode.ingr.com (Greg Henderson) writes:
] 
[...Greg posts an array scan and a pointer scan, deleted for brevity...]
]
] The presumption here is that the length of int is same as
] the length of the address space.

    How do you mean "address space"?  You mean alignment or the size of
the addressable area of memory considered as an integer?  I don't think
either should mess you up here.

    Also, I'm not sure which program you're objecting to.  There are two
here.

In article <1992Aug27.135946.6622@infonode.ingr.com> henders@infonode.ingr.com (Greg Henderson) writes:
=
={
=    int a[1000], *_i;
=
=    for (_i=a;  _i<a+1000; _i++ )
=	*_i = get_some_arbitrary_value();
=}

    I assume this is the one, right?  Well, by ANSI (and all pre-ANSI
compilers that I've seen), a[] must be a *contiguous* set of int's, and
_i must get initialized to &a[0].  So after _i++, _i must point to a[1],
no?

    The only objection I have is "_i": ANSI says that starting
identifiers with underscores a no-no.  (Unless you're personally writing
the compiler,...)

] If the int is 4 byte long and the address space is 2(or 8 or 3) byte long,
] the this fell miserably. The second one is not portable.

    If by "address space" you mean alignment, then it must be the case
that
        (&a[1] - &a[0])
is 4 (or 8 or 4, by your examples), and
        ((_i = a, ++_i) - &a[0])
must also be 4 (or 8 or 4).

    (And, c.l.c fans, quote me no sequence points: the last expression
was just for example, and would be used by no one in their right mind.
It only fails if you don't understand what I mean, not if it doesn't
produce a good run-time value.)

    If by "address space" you mean the addressable area of memory,
declaring "int a[1000]" will either succeed (in which case, a[1000] will
point to valid memory), or the program will crash on an "out of stack"
error, or it will fail to compile/link.

                                           -- Bill K.

Bill Kaufman,          | "...all conscious species are plastic and
Corporate Lackey       |  all plastic species are conscious."
wkaufman@us.oracle.com |                     -- Yew-Kwang Ng
From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Newsgroups: comp.lang.c
Subject: Re: strcpy implementation question
Date: 4 Sep 92 16:15:40 GMT
Article-I.D.: mulga.9224902.15217
Organization: Computer Science, University of Melbourne, Australia

pinkas@skywalker.intel.com (Israel Pinkas) writes:

>ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>
>RK> When is the size of the source known at compile time?  Two cases:
>RK> (a) the source is a string literal (or is a pointer whose value is known
>RK>     by constant propagation to be a specific string literal)
>RK> (b) the code looks something like
>RK>  if (strlen(x) == 27) { /* don't change x */; strcpy(d, x); ...}
>
>Not quite.  I said that the size of the source and destination are known,
>not the length of the string.  If the length of the string is known, and it
>can be guaranteed to be inviolate, we only have to copy enough bytes to
>move the string.  However, strings are not inviolate, as the middle of the
>string can be modified in ways that the compiler cannot control, such as
>signal handlers.

Actually, in a strictly conforming program, a signal handler should only
modify variables of type "volatile sig_atomic_t". More liberally, most
compilers will allow a signal handler to modify variables of any type, but
they should be declared as "volatile".

If the string is not declared as volatile, then the compiler should be
able to assume that the string *is* "inviolate".

>The only way a compiler can know the size of a char array is:
>    (a) It is a string literal.
>    (b) It is an array declared at compile time, with dimension(s).

Well, a smart compiler might be able to determine that after
	char *s = (chart *) malloc(100);
that s points to a char array of size 100.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.lang.c
From: svec5@menudo.uh.edu (T.C. Zhao)
Subject: Re: C vs. FORTRAN
Organization: University of Houston
Date: Fri, 4 Sep 1992 00:18:42 GMT

In article <1992Sep3.225136.27006@nrao.edu> cflatter@nrao.edu writes:
>In article 92Sep3164036@spsd630a.erim.org, dwiseman@spsd630a.erim.org (Dave Wiseman) writes:
>>
>>Help!
>>
>>I have a (two) simple programs, one in fortran, and one in C.  I have compiled
>>them both optimized, and timed the results.  The fortran version takes .1 s
>>to run, and the C version takes 12.5s to run.  I know (hope) that there is a
>>	Dave Wiseman
>>	dwiseman@erim.org
>>
>>-------------------------------------------------------------------------------
>>#include <stdio.h>
>>#include <math.h>
>>
>>main (argc,argv)
>>     int argc;
>>     char **argv;
>>{
>>  double angle,delta,the_sin,the_cos;
>>  int i;
>>  
>>  angle = 0.0;
>>  delta = 0.01;
>>  
>>  for (i=0; i<1000000; i++)
>>  {
>>    the_sin = sin(angle);
>>    the_cos = cos(angle);
>>    angle += delta; 
>>  }
>>}
>>-------------------------------------------------------------------------------
>>      program test
>>
>>      real*8 angle,delta,the_sin,the_cos
>>      integer*4 i
>>
>>      angle = 0.0
>>      delta = 0.01
>>
>>      do I=1,1000000
>>         the_sin = dsin(angle)
>>         the_cos = dcos(angle)
>>         angle = angle + delta
>>      enddo
>>
>>      end
>
>Beware of timing trivial programs.  Since the first 999 999 values of the_sin
>and the_cos are discarded an optimised is at liberty to avoid computing them.
>It is likely that the FORTRAN compiler did this and while the C compiler
>did not.  I am fairly sure that if the_sin and the_cos were made into arrays
>and if the sin and cos results were stored into the_sin(i) and the_cos(i)
>on every loop the C and FORTRAN versions would take almost exactly the
>same time to run.
>
>The only other likely possibility is that the FORTRAN compiler is exploiting
>a hardware implementation of the transcendental functions while the C compiler
>is not.  This is only a significant possibility on Intel 80x86/80x87 machines
>and since the 0.1 second time for the FORTRAN implies a floating-point
>performance in excess of 30 MFLOPS it is a very remote one.
>
>	Chris Flatters

Yet another possibility (although it won't explain the huge difference):
Fortran compiler knows the sin and cos functions and hence there is
a possibility to do inlining while C compiler is not aware of these
functions and there is no possibility of doing so without violeting
the standard.


Newsgroups: comp.lang.c
From: RICHARD@CLYDE.ttt.kth.se
Subject: Re: printf question
Organization: Department of TeleTransmission Theory
	<1226@pascal.einstein.eds.com>
Date: Sun, 30 Aug 1992 14:31:24 GMT

   In article <kimcm.714943581@login.dkuug.dk> kimcm@login.dkuug.dk (Kim Chr. Madsen) writes:

[... text deleted ...]

   >try to use the variable width specification method:
   >
   >	printf("%0*x\n",4, adress);
   >
   >an asteriks in the width specification is taken as a variable that
   >must be taken from the arguments and be evaluated at runtime...

   The above will work just fine, but if you have a full ANSI compiler, the
   syntax ...

   #define HDPI "4" /* Hex Digits Per Int */

	   printf( "%0" HDPI "x\n", address );

[... text deleted ...]

   And if you have read this far, you surely won't mind one more irrelevant
   remark ;-)  Using this syntax on the original problem will save you some
   time because the format is evaluated at compile time instead of run time.

Huh????? Since when is the format evaluated at compile time? I've never
seen that done!

--
!+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++!
! Richard Levitte, System manager       ! tel: int+46-8-790 64 23           !
! Royal Institute of Technology         ! fax: int+46-8-791 76 54           !
! Department of Teletransmition Theory  ! Internet: richard@ttt.kth.se      !
! S-100 44 Stockholm, Sweden            !                                   !
!---------------------------------------------------------------------------!
Newsgroups: comp.lang.c
From: u8705957@cs.uow.edu.au (Hitesh Sanghvi)
Subject: HELP !! Converting non printable characters to HEX
Organization: Dept of Computer Science, Wollongong University, Australia
Date: Tue, 1 Sep 1992 15:21:49 GMT

Hi there;
	Any suggestion or 'c' code on how to convert non printable 
characters to hex.
My function works for printable ascii characters but does not work
on non printable characters.

My code is as follows:

void
dec_to_hex(sin,sout)
unsigned char sin[],sout[];
{
	int loop,i;

	for (loop = 0;loop<4;loop++)
	{
		i = (int)sin[loop];
		sprintf(&(sout[2*loop]),"%02x",i);
	}
}
so it takes 4 ch and gives me 8 hex ch onlly when ascii ch is entered.

Prompt response will be appriciated.

Thank you very much.

HITESH SANGHVI
email : u8705957@cs.uow.edu.au
From: adrian@mti.mti.com (Adrian McCarthy)
Newsgroups: comp.lang.c
Subject: Re: Most difficult part of learning C?
Date: 28 Aug 92 17:08:10 GMT
Organization: Micro Technology, Inc., Anaheim, CA

I think one of the things the successful C programmers often *never* get
is learning the distinction between what is part of the C language and
what is part of their environment.

I know several people who have programmed in C in the UNIX (mostly Sun)
environment for many years who *never* realized that:

	o creat(), open(), close(), fork(), getopt(), etc., are part of the
	  UNIX libraries and not an inherent part of C.
	o expressions like a[i++] = i may evaluate differently on different
	  compilers.  Many compilers and lints won't warn you when you use
	  something like this.
	o exit codes are interpretted by the host OS (if there is one), so
	  exit(1) isn't always the right way to signal an error.

Unless your learning experience includes an instructor looking over your
shoulder and reminding you of these things, it's very easy to confuse parts
of the environment with the language.  Some books do a good job of emphasizing
these distinctions, others just mention it in passing.  As a result, a
successful C programmer who has experience with a single environment can
find life very difficult when they are transplanted or must work simultaneously
in two environments.

These problems (especially the first) can happen with most languages, of
course, but it seems to happen more with C programmers.  Perhaps that's
because so many C packages offer a library of UNIX library emulation routines,
thus delaying the painful gotcha that happens when you finally realize the
difference between a language run-time library features and a host OS feature.

Aid.  (adrian@lexcel.com)
Newsgroups: comp.lang.c
From: rsaripa@neptune.cs.clemson.edu (Saripalli Ramakrishna)
Subject: Function definition?.
Organization: Clemson University Computer Science Dept.
Distribution: na
Date: Wed, 2 Sep 1992 16:24:22 GMT

Hi,

	This may seem like a stupid question,but surely it may provoke some
	interest.Is there any way to find out if a certain function is defined
	in a certain source file,given its corresponding executable file?.

					Thanks a lot,
					Saripalli Ramakrishna

e-mail : rsaripa@cs.clemson.edu
Man is a beast and usually has no control over his passions.
Newsgroups: comp.lang.c
From: carl@aslmr-serv.med.ge.com (Carl Crawford)
Subject: sun cc optimization failure
Reply-To: carl@aslmr-serv.med.ge.com (Carl Crawford)
Organization: GE Medical Systems, Milwaukee,  WI
Date: Thu, 3 Sep 92 04:04:01 GMT


consider the following program:

main() {
	int i,j,ax;
	ax = 0;
	for(i=0;i<3;i++){
		j = ax * i;
		puts("in for loop");
	}
}
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. hom come the optimization 
screws up the loop?
--
Carl R. Crawford	   Voice: 414-521-6572
GE Medical Systems	   Fax: 414-521-6575
P.O. Box 414, W-875	   Internet: crawfordc@med.ge.com
Milwaukee, WI 53201
From: chen@force.ssd.lmsc.lockheed.com
Newsgroups: comp.lang.c
Subject: need with help on curses
Date: 26 Aug 92 15:35:08 GMT
Article-I.D.: enterpri.1992Aug26.153508.27257
Reply-To: chen@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California

I need help with curses.  I am new to UNIX and C.  I am currently
working with curses (yes, curses and not cursors), a screen control
library package in C, to write a generic user interface. 

I am displaying a menu in a window (win1).  When one of the menu items
is chosen, another window(win2) is displayed on top of win1 (partially
overlapping win1) for the user to input data.  Upon completion of data
entry, win2 should disappear and win1 fully displayed. 

I have not been able to get win2 to disappear and the best that I can
do right now is to have win1 "brought forward on top" of win2.  Has
anyone done any programming with curses?  

Does anyone know of any good books on curses or have any curses menu 
routines that I may have?  Please help.  Thank you. 

-Phillip  chen@lmsc.lockheed.com
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: Novice Questions
Date: 30 Aug 92 16:26:57 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <1992Aug30.004740.8973@eskimo.celestial.com>, maven@eskimo (Norman Hamer) writes:
> 1. Given a char array, say char foo[256];, is *foo the same as foo[0]

Yes: foo[0] becomes *(foo+0) becomes *foo.

>and is foo+x the same as foo[x] in all implementations?

No.  As I indicated above, foo[x] is the same as *(foo+x).
(so &foo[x] is the same as foo+x)

> 2. What's the best way to read in a text configuration file? I've seen
>code like this:

[other options deleted]
> while(fgets(line, 80, fd) != NULL)
> {
>   /*Muck with the data */
> }

This is the way I've seen it done most often (at least in C), and I prefer
it.  It's the simplest of the lot, and therefore the easiest to get right,
and the easiest to understand later.  As you pointed out with the others,
you have to be very careful to be sure you got the control flow and calls
to feof() just right, or you're screwed.

-- 
--- jumbo shrimp --- pretty ugly --- awfully nice --- constant change ---
Xref: sparky comp.lang.c:12883 comp.unix.programmer:4471
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Newsgroups: comp.lang.c,comp.unix.programmer
Subject: Re: I/O With Unix/C
Date: 27 Aug 92 19:03:34 GMT
Organization: SAS Institute Inc.
Originator: sasghm@theseus.unx.sas.com


In article <ZcB7PB1w164w@underg.UUCP>, max@underg.UUCP (Max Cray) writes:
|> Help!
|> 
|> I am trying to do the most basic file I/O on a couple of unix machines (HP835,
|> and Sequent S27), and I can not get it to work. For example:
|> 
|> #include <stdio.h>
|> main()
|> {
|>     int c;
|> 
|>     while (c = getchar() != NULL)
|>         putchar(c);
|> }
|> 
|> On a DOS machine you just compile it, and it works. When I compile it on

I don't think so.  I think it *appears* to you to work.

|> What am I missing?

Some parentheses.  The value of 'c' will always be '1' since your
line is equivalent to

	while ( c = (getchar() != NULL) )

That is, 'c' gets the value of the *comparison*.  I guess what you
intend is

	while ( (c = getchar()) != NULL )

but I think you probably want to check EOF instead of NULL.
-- 
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