Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker.mit.edu!apple!agate!ziploc!eps
From: eps@toaster.SFSU.EDU (Eric P. Scott)
Newsgroups: comp.sys.next
Subject: Re: 2.0 bugs/features
Message-ID: <1086@toaster.SFSU.EDU>
Date: 3 Jan 91 06:31:52 GMT
References: <1990Dec29.190758.18458@athena.mit.edu> <1083@toaster.SFSU.EDU> <1991Jan1.210406.10546@athena.mit.edu>
Reply-To: eps@cs.SFSU.EDU (Eric P. Scott)
Organization: San Francisco State University
Lines: 114

[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=-