ra@is.uu.no (Robert Andersson) (10/03/90)
Having just upgraded our 4x0 and 6x0 machines from 2.01.01 to 3.00.01,
I thought some of the problems I have run into might interest others.
This is a long, and fairly techical message, here goes..........
1. C compilation system.
a) The optimizer now is *very* clever at omitting unneeded frame pointer
and stack pointer operations. Be aware however, that this will cause
problems when porting code that uses the infamous alloca(3) function.
This is especially true for all GNU software.
I have found it necessary to either:
a) Disable optimizations, or
b) Link with the C version of alloca.
Anybody out there aware of some undocumented option that tells the
optimizer to always make a frame pointer, and to don't delay stack
pointer adjustments?
b) When optimizing at the -O2 level, the optim program is *extremely*
slow if you have programs with very large functions. In fact, it
is so slow sometimes it borders on being useless. I had a 2000 line
C program that optim worked on for 30 CPU-minutes, at that stage I
aborted it, and never bothered to check if it ever managed to finish.
Unfortunately, this type of program is often the output of yacc, or
other 'state machine' type programs, where you have an enormous
function with a switch statement and a case label for each state.
c) When compiling with -g, the optimizer level is still -O2. This is
contrary to most other systems I have seen. It shouldn't be necessary
to specify -g -O0. This problem is amplified by b) above.
d) cc -p and prof is completely broken for programs with a text region
bigger than 64Kb. This was also the case for the V.2 releases, but
thanks to Mike Wescott of NCR I managed to patch around it there.
e) The -iistring.h directive in /lib/default.cpp causes all programs
that use cpp directly as a general macro preprocessor to fail.
I have found it necessary to delete this directive.
f) /usr/include/imemory.h has two *syntax* errors in it. Has this ever
been tested?
g) The C compiler often leaves files in /tmp when interrupted with
SIGTERM.
2. Documentation omissions.
a) Several areas of the Programmer Reference manual, D1-1057-B, have not
been upgraded to the V.3 level. This is at least true for:
a) mkdir(2) and rmdir(2)
b) getdents(2)
c) All the new reliable signal system calls.
d) terminfo(4)
b) dup2
c) strdup
d) The installation instruction fails to mention that the userid's
'uucp' and 'listen' are created, and with no passwords. This
creates a security hole if the sysadmin forgets them.
3. Misc.
a) The V.3 uucp changes to handle intelligent modems without carrier
detect strapped high do not work. See the hayes section in
/usr/lib/uucp/Dialers. My guess is that the Tower tty driver has
the same bug as almost all others, namely that opening a tty device
with O_NDELAY, then toggling NDELAY off with fcntl, then setting
CLOCAL with ioctl, then doing read, does not work.
b) The fact that all software linked with the V.2 terminfo library
does not work at all with the V.3 terminfo library has caused
several problems. While it's theoretically easy to set
TERMINFO=/usr/lib/terminfoV2 before running the program, this
breaks down when said program provides shell escapes.
I don't know if it's AT&T or NCR that messed up this.
c) The compress utility supplied by NCR has been changed compared to
the one in the public domain. The -d flag is not accepted, this
causes for instance Cnews to fail. I deleted the NCR software
and installed the public domain version instead.
d) I'm confused by the Tower OS support for symbolic links. It seems to
be partly like in BSD and partly not. Unfortunately, several programs
available by FTP or through Usenet, check for the existence of the
S_IFLNK macro in /usr/include/sys/stat.h, and if it's there assumes
full functionality BSD symlinks. This assumption is wrong, and the
program fails. Perhaps NCR should have used another name than S_IFLNK,
or implemented the full BSD symlink semantics?
--
Robert Andersson, International Systems A/S, Oslo, Norway.
Internet: ra@is.uu.no
UUCP: ...!{uunet,mcsun,ifi}!is.uu.no!ra