Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!tut.cis.ohio-state.edu!snorkelwacker.mit.edu!bloom-picayune.mit.edu!news From: gerry@x-ray.mit.edu (Gerald Swislow) Newsgroups: comp.sys.next Subject: Re: 2.0 bugs/features Message-ID: <1991Jan1.210406.10546@athena.mit.edu> Date: 1 Jan 91 21:04:06 GMT References: <1990Dec29.190758.18458@athena.mit.edu> <1083@toaster.SFSU.EDU> Sender: Gerry Swislow Followup-To: gerry@x-ray.mit.edu Organization: Certified Scientific Software Lines: 108 In article <1083@toaster.SFSU.EDU> eps@cs.SFSU.EDU (Eric P. Scott) writes: >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. I stopped in at the MIT Tech Coop and looked in an ANSI C book where I saw that atof() has "#include " on its manual page. So that's where the standards folks decided to put it ... Well, I don't mind it being there, but do the standards folks require that NeXT remove it from where it had lived, lo, these many years? Why get rid of backwards compatibility for the sake of tidyness? Using "-bsd" on the NeXT will change nothing with respect to atof(). >>4) You don't get core dumps unless you do an >> unlimit core >> command from somewhere. > >This is nothing new. NeXT 2.0 is the first system I have come across that has core dumps disabled as the initial default, and that is something new. It may have been present since BSD 4.2 for all I know, but I had never heard of it (having never had need for it) and had to call NeXT to find out how to get those handy core files back. The reason NeXT disables core files, no doubt, is because the shared library text image makes them so much larger. This program: main() { pause(); } when killed with ^\ generates a 1.4 Mbyte core file, for example. Sun, on the other hand, has core files that say they are 8Mb, but are actually full of holes and only consume a minimal amount of disk space. (Unless, of course, you make copies of them.) >>5) [description of problems with losing charcaters when >> telneting into the NeXT from ISC 386/ix 2.0.2 system] > >[EPS talks about various TPC/IP protocols and wonders if >whatever I am using is sound ...] Does anybody else who has a NeXT with release 2.0 have any problems with telnet or rlogin when calling into the NeXT on ethernet? My NeXT is not on Internet, so I can't do any testing. However the same 386 software is installed on friends' computers on the internet, and they report no problems talking to an assortment of platforms (near and distant) using telnet and rlogin. I had no problems with telnet on NeXT release 1.0, so I am wondering if I am alone with my troubles with 2.0. >> 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. I'm sure you are right about this. I knew the csh was fiddling with the tty driver modes between prompts, but didn't figure out why. I never use file name completion. >> 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. You are wrong about shared library behavior on the Sun. The Sun C compiler/linker does not consider functions in shared libraries to be reserved names. The -Bstatic flag prevents linking from shared libraries, so your last comment makes no sense. Static or dynamic, the Sun linker doesn't care what names you use (at least up to and include SunOS 4.0). I have no problems in adapting my code to conform to NeXT's new rules. I just question whether those new rules are in the spirit of C. There used to be about 32 reserved names (if, while, do, break, etc.) Now there are an unlimited number corresponding to every function a vendor chooses to stick in a shared library, at least in the NeXT scheme of things. I could certainly see arguments for reserving the names used in the libraries, but it is probably worth a mention in NeXT's release notes, at the least. Gerry Swislow - - - - - - - - - - - - - - - - - - - - - - - - Certified Scientific Software Internet : gerry%certif@x-ray.mit.edu PO Box 390640 BITNET : gerry%x-ray.mit.edu@MITVMA Cambridge, MA 02139 phone : (617) 576-1610