Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!olivea!apple!agate!ziploc!eps From: eps@toaster.SFSU.EDU (Eric P. Scott) Newsgroups: comp.sys.next Subject: Re: 2.0 bugs/features Message-ID: <1083@toaster.SFSU.EDU> Date: 31 Dec 90 03:46:29 GMT References: <1990Dec29.190758.18458@athena.mit.edu> Reply-To: eps@cs.SFSU.EDU (Eric P. Scott) Organization: San Francisco State University Lines: 80 In article <1990Dec29.190758.18458@athena.mit.edu> gerry@x-ray.mit.edu (Gerald Swislow) writes: >1) The declaration of atof() as a function returning a double > is no longer made if you include . In release 1.0, > math.h included which contained the declaration. Given that #include isn't specified on the man page for atof, I'm going to claim this is proper behavior for "ANSI" C. If you compiled -bsd then it should be defined. >4) You don't get core dumps unless you do an > unlimit core > command from somewhere. This is nothing new. >5) Using telnet to talk to the NeXT from somewhere else (in my case > a 386 running AT&T System V/386) and running "csh" on the NeXT > has become quite flaky. The NeXT people say that they added > something called > stty -extproc > that helps somewhat. It solved the problem of losing characters > but if I type ^S to stop a scrolling screen, things often get > hopelessly hung, requiring me to kill processes on the 386 end. > I had no problems with telnet on release 1.0a. External processing was added to support linemode telnet [RFC 1184, although what NeXT ships with 2.0 is probably based on the earlier RFC 1116]. It's not something that users should normally change. Proper handling of ^S/^Q requires support for remote flow control [RFC 1080] or linemode telnet. If the telnet on your '386 doesn't support either of these, you can't expect ^S/^Q to work properly. (You didn't say whose TCP/IP you have-- Lachman? TWG? ...or are you running V.4?). I don't think NeXT is at fault here, but you can expect to see an improved telnetd in the future--the Borman brothers are still tinkering with it at Cray Research. The current one should be a lot happier over low- speed links (e.g. SLIP) or when talking to Annex II terminal servers. > "rlogin" still > loses huge blocks of characters, -extproc or not. This was > also the case on release 1.0a. This is an intrinsic failing of the rlogin protocol--it does not work properly on ANY system because of the way it (mis)uses TCP urgent data. You tend to "get lucky" between machines on the same Ethernet (or close to it). On the greater Internet, it ain't so. > Interestingly all these problems > are only when running the "csh". If I type "sh", commands such > as "ls -l /bin" do not drop characters. What's getting you is switching in and out of cbreak mode for csh file completion. You'll have the same problems on any other UNIX machine if you say set filec; NeXT's csh doesn't let you disable this, so you lose. > you can no > longer define a function that uses the same name as one of the > C library functions or system calls in the shared library. > The NeXT > people say they had to do this because of shared libraries. Sun > shared libraries don't care if you redefine names, so it doesn't > seem as though NeXT had to do this. Assume that shared libraries are "prelinked"--if you call something that calls something with the same name as one of your procedures, you end up with a conflict. NeXT didn't invent this; System V exhibits the same behavior. Try cc -Bstatic on your Sun and tell me whether you still think your code is kosher. -=EPS=-