karl@grebyn.com (Karl A. Nyberg) (09/13/90)
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 -- Karl --
mjr@decuac.DEC.COM (Marcus J. Ranum) (09/13/90)
In article <21955@grebyn.com>, karl@grebyn.com (Karl A. Nyberg) writes:
: > [...] 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.
That's not a problem with the operating system, the assignment to
fileno() in your code is broken.
Assigning to fileno() is evil.
mjr.
--
Eagles may soar, free and proud, but weasles never get sucked into jet engines.envbvs@epb2.lbl.gov (Brian V. Smith) (09/13/90)
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.
chris@mimsy.umd.edu (Chris Torek) (09/14/90)
In article <1990Sep13.084901@epb2.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes: >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;" This really is no better: assigning to _file is just as bad. (Nowhere in the documentation does anything say that there *is* a _file field, so the implementation is free to change this.) The real solution is to change the algorithm. Unfortunately, the hack is much easier. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
mjr@hussar.dco.dec.com (Marcus J. Ranum) (09/16/90)
In article <1990Sep13.084901@epb2.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes: >The answer is to change the "fileno(fp) = -1;" to "fp->_file = -1;" >and "fileno(fp) = fno;" to "fp->_file = fno;" What I don't understand about all this (and I won't, unless I look at the code) is why they are setting the file descriptor to -1 anyhow. That seems kind of dubious to me. stdio is well behaved and works portably unless you start to grub around in its private data. fclose() is a better way of disabling a FILE * than setting its file descriptor to -1, and fdopen() is a better way of wrapping a FILE * around an existing file descriptor. mjr. -- Any viewpoints expressed in this posting are not necessarily shared by Digital Equipment, Inc., the poster's supervisor, or the poster's cats. -- Eagles may soar, free and proud, but weasles never get sucked into jet engines.
klg0582@uxa.cso.uiuc.edu (Ken-Huang Lin) (09/18/90)
I am sorry to post this silly question. Does DEC have an ANSI C for ultrix? I am not a regular reader in this news group, so please send me mail. thanks in advance, Ken H. Lin lin@uiwpl.ece.uiuc.edu