Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!dog.ee.lbl.gov!epb2.lbl.gov!envbvs
From: envbvs@epb2.lbl.gov (Brian V. Smith)
Newsgroups: comp.unix.ultrix
Subject: Re: stdio.h problem on 4.0 (was News 2.11.19...)
Message-ID: <1990Sep13.084901@epb2.lbl.gov>
Date: 13 Sep 90 15:49:01 GMT
References: <421@ucunix.SAN.UC.EDU> <21955@grebyn.com>
Sender: usenet@dog.ee.lbl.gov
Reply-To: envbvs@epb2.lbl.gov (Brian V. Smith)
Organization: lbl
Lines: 29
X-Local-Date: Thu, 13 Sep 90 08:52:09 PDT

In article <21955@grebyn.com>, karl@grebyn.com (Karl A. Nyberg) writes:
|> In article <421@ucunix.SAN.UC.EDU> rainwatr@ucunix.san.uc.edu (Don Rainwater)
writes:
|> 
|> >is that I can't compile the file rfuncs2.c because it doesn't like
|> >having fileno(fp) on the lhs of an assignment operator.  (The offending
|> >lines are 314 and 316 in this file, if you're interested.  314 is
|> >something like "fileno(fp) = -1;" and 316 is "fileno(fp) = fno;")
|> 
|> This is definitely a problem with Ultrix. 4.0.  I just tried recomiling
|> X11R4, fix 14 and got the SAME problem with Xterm.  it has to do with the
|> declaration of fileno in /usr/include/stdio.h.  The Ultrix 4.0 version has
|> added a cast of (int) over the 3.0 version.  This causes some real problems
|> on the lhs of an assignment statement.
|> 
|> Solutions: (1) edit /usr/include/stdio.h to drop the cast
|> 	   (2) hand expand the macro
|> 

Maybe my post didn't make it the first time.
Also, as Marcus Ranum of DEC says, "assigning a value to fileno is evil."

The answer is to change the "fileno(fp) = -1;" to "fp->_file = -1;"
and "fileno(fp) = fno;" to "fp->_file = fno;"

--
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL; they don't pay me enough for that.