gerry@x-ray.mit.edu (Gerald Swislow) (12/30/90)
Here are a few bugs and/or features I have found on Release 2.0.
(Ask_NeXT has been informed.)
1) The declaration of atof() as a function returning a double
is no longer made if you include <math.h>. In release 1.0,
math.h included <stdlib.h> which contained the declaration.
(It took me hours to figure out why my programs were producing
funny numbers because of this little thing.)
2) /usr/bin/less does a core dump if you use the "E" command
while running. The "E" command lets you examine another file.
I replaced this "less" with the one from release 1.0.
3) The Icon application dies if you tickle the menus up and
down. This is very peculiar. There is probably just one sensitive
spot on the menus and you just need to learn to avoid it, I suppose.
4) You don't get core dumps unless you do an
unlimit core
command from somewhere. I do it from a .login file for an
interactive csh. Maybe there is some netinfo setting for it?
You can also limit the size of core dumps. If the directory
/cores exists and is writable, core dumps will be put there
and named "core.pid" with pid being the process id.
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. "rlogin" still
loses huge blocks of characters, -extproc or not. This was
also the case on release 1.0a. Interestingly all these problems
are only when running the "csh". If I type "sh", commands such
as "ls -l /bin" do not drop characters.
6) The NeXT people say that the following is done on purpose, but
it seems a little arbitrary to me. Anyway, 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. Of
course you can easily change the names of your functions in your
code, but those old sources that provided their own versions of
printf(), memset(), strchr(), malloc() or whatever will get a
fatal error from ld when you compile them. 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. In my code (which I port
to every incarnation of UNIX) I had gotten tired of setting cpp
flags as to whether a particular system used strchr() or index(),
strrchr() or rindex(), memclr() or bzero(), etc., and so I just
supplied my own versions of strchr(), strrchr(), etc.
That worked fine until I compiled on 2.0. I have now changed the
names of my routines to Strchr(), Strrchr(), etc.. No big deal.
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-1610eps@toaster.SFSU.EDU (Eric P. Scott) (12/31/90)
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 <math.h>. In release 1.0, > math.h included <stdlib.h> which contained the declaration. Given that #include <math.h> 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=-
gerry@x-ray.mit.edu (Gerald Swislow) (01/02/91)
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 <math.h>. In release 1.0, >> math.h included <stdlib.h> which contained the declaration. > >Given that #include <math.h> 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 <stdlib.h>" 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
eps@toaster.SFSU.EDU (Eric P. Scott) (01/03/91)
[Would you please stop putting e-mail addresses in Followup-To: headers? Only newsgroup names (or the reserved word "poster") should appear there. Use Reply-To: to direct e-mail responses. I hope the people working on the "next generation" newsreaders include some reasonable sanity checking...] In article <1991Jan1.210406.10546@athena.mit.edu> gerry@x-ray.mit.edu (Gerald Swislow) writes: >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(). Not having a 2.0 system in front of me to confirm this, I'd have to say "NeXT goofed" on this one; it should be in math.h under __STRICT_BSD__ conditionals ("real" BSD declares atof() in both math.h and stdlib.h--K&R C programs can use either, but prefer the former; ANSI or C++ code MUST use the latter). >>>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. Let me clarify this; it's not a change from NeXT 1.0 to NeXT 2.0. > The reason NeXT disables core >files, no doubt, is because the shared library text image makes them so >much larger. That's not what I heard--NeXTfolk said it was due to the way Mach memory management works (look at the VSIZEs on a ps -u), and this is true whether or not shared libraries are used. >>>5) [description of problems with losing charcaters when >>> telneting into the NeXT from ISC 386/ix 2.0.2 system] > >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. One more time: Most UNIX workstation vendors are still shipping 4.3 or 4.3-tahoe versions of telnetd. NeXT 1.0/1.0a included a May 1986 telnetd. NeXT 2.0 includes a June 1990 version that "breaks" some telnet clients--clients with latent bugs. For example, I've seen clients represent telnet option state as bits in long integers. Since 4.3-tahoe (and SunOS 4.1 and HP/UX 7.0, for example) don't offer any options numbered higher than 24, this strategy works. In December 1988, option #32 was specified; non-experimental implementations didn't appear until later. Suppose you have a client that "forgets" to do bounds checking for options >=32. When it connects to a current BSD telnetd or VAX/VMS+MultiNet system, it's going to trash part of itself. You'll see that as software "that's worked right for years" breaking, even though it's really been "broken" all along. Our users have had 1990 vintage telnet/telnetd on several NeXT 1.0/1.0a systems for several months with very few problems reported--in all cases the problems turned out to be on the other end. While we've tested against a fair number of implementations, ISC UNIX is not one of them. I've been told that versions of their TCP/IP package from before about July 1990 had serious defects. Sorry, I don't know the exact version numbers. >You are wrong about shared library behavior on the Sun. Reread what I wrote. > Static or >dynamic, the Sun linker doesn't care what names you use (at least >up to and include SunOS 4.0). Ah. You're not running 4.1 yet. You're in for a surprise. I got ld: /lib/libc.a(malloc.o): _malloc: multiply defined [Credit where credit is due: I first learned about the change in SunOS 4.1 from Patch 6 to ELM 2.3. Since I generally don't do "stupid things" in my code, I haven't suffered.] >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. The C language hasn't changed. You've acted on some bad assumptions. >There used to be about 32 reserved names (if, while, do, break, etc.) The reserved words haven't changed. >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. (1) AT&T System V shared libraries exhibit the same behavior. (2) You should still be able to usurp procedure names that aren't referenced by anything you pull in from outside. It's virtually impossible to get away from something like malloc(). (3) Anything in a shared library you don't link against can't hurt you. NeXT's "weird stuff" is in libNeXT rather than libsys. (4) NeXT's contributions have names beginning with NX, which makes it unlikely that they will conflict with your own identifiers. -=EPS=-