Mailing List Archive

Mostly good news on the NeXT front.
I'll be able to test on next 4.2 after the initial 3.3 port.

I have a vsnprintf/snprintf that compiles (works?) on NeXT. Not sure how
portable nor if it truely solves the security issue (it's from the
comp.sys.next.programmer fokes). Plus NeXT 3.3 (not sure about 4.2 yet)
lacks a putenv(). I found one that compiles cleanly from the GNU libc
fokes. Which brings up licensing issues. I'm not sure if we can get a
wavier or if we will have to write our own. It looks simple enough to
rewrite if we have to. I personally hate reinventing wheels.

But things are slowly compiling. It does look like I am missing poll()
(I believe older versions of Linux has this problem so I may be able to
find sample code) and the whole mem*() functions are very poorly
documented so it should be interesting. (It exists in the libposix.a, but
no manpages)

The "ssh" program compiled, but on attempting to connect I get a coredump
and a nice "Floating exception" error. (It would not suprise me if my
vsnprintf/snprintf are incorrect, but I've not bothered to trace it yet)

But hey.. We have least progress.. And after finding -posix and
-D_POSIX_SOURCE cc flags I have less #ifdef and things are compiling
much cleaner. So maybe next week sometime I may have patches. (Looks
like 2 or 3 #ifdef now instead of 10 =)
Re: Mostly good news on the NeXT front. [ In reply to ]
On Wed, Jan 12, 2000 at 02:28:15AM -0600, Ben Lindstrom wrote:
>
> I'll be able to test on next 4.2 after the initial 3.3 port.

> I have a vsnprintf/snprintf that compiles (works?) on NeXT. Not sure how
> portable nor if it truely solves the security issue (it's from the
> comp.sys.next.programmer fokes). Plus NeXT 3.3 (not sure about 4.2 yet)
> lacks a putenv(). I found one that compiles cleanly from the GNU libc
> fokes. Which brings up licensing issues. I'm not sure if we can get a
> wavier or if we will have to write our own. It looks simple enough to
> rewrite if we have to. I personally hate reinventing wheels.

is libc under the LGPL? If so, and I think it is, its license isn't
incompatable with distributing the rest of the package under the
BSD-ish license it has.

--
David W. Rankin, Jr. Husband, Father, and UNIX Sysadmin.
Email: drankin@bohemians.lexington.ky.us Address/Phone Number: Ask me.
"It is no great thing to be humble when you are brought low; but to be humble
when you are praised is a great and rare accomplishment." St. Bernard
Re: Mostly good news on the NeXT front. [ In reply to ]
På 2000-Jan-12 klokka 02:28:15 -0600 skrivet Ben Lindstrom:

: [...] Plus NeXT 3.3 (not sure about 4.2 yet) lacks a putenv(). I found
: one that compiles cleanly from the GNU libc fokes. Which brings up
: licensing issues. I'm not sure if we can get a wavier or if we will
: have to write our own. It looks simple enough to rewrite if we have
: to. I personally hate reinventing wheels.

Ben, does NeXT have setenv()? If it does, you might be able to get
away with making a wrapper that uses either putenv() or setenv(),
depending on what's available. That would be much better than trying
to use glibc code.

--
jim knoble
jmknoble@pobox.com
Re: Mostly good news on the NeXT front. [ In reply to ]
On Wed, 12 Jan 2000, Jim Knoble wrote:

> På 2000-Jan-12 klokka 02:28:15 -0600 skrivet Ben Lindstrom:
>
> : [...] Plus NeXT 3.3 (not sure about 4.2 yet) lacks a putenv(). I found
> : one that compiles cleanly from the GNU libc fokes. Which brings up
> : licensing issues. I'm not sure if we can get a wavier or if we will
> : have to write our own. It looks simple enough to rewrite if we have
> : to. I personally hate reinventing wheels.
>
> Ben, does NeXT have setenv()? If it does, you might be able to get
> away with making a wrapper that uses either putenv() or setenv(),
> depending on what's available. That would be much better than trying
> to use glibc code.
>
Nope already looked for the non-posix setenv() call. I'll have to look
at the header from the putenv() the gnu libc fragment I have. I know
it was dated 1991. Which if I'm not mistaken is pre-LGPL. But I suspect
that it would not be hard to get a wavier to at least LGPL if it's not
already.

If anyone was on #unixhelp/#nixhelp on efnet last night you would have
heard me curse up and down about lack of native libc functions on
NeXT.=)
Re: Mostly good news on the NeXT front. [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 12 Jan 2000, Jim Knoble wrote:

> Ben, does NeXT have setenv()? If it does, you might be able to get
> away with making a wrapper that uses either putenv() or setenv(),
> depending on what's available. That would be much better than trying
> to use glibc code.

I have a replacement setenv which uses putenv already in bsd-misc.c.

It would be amusing to have to do the reverse as well.

Damien

- --
| "Bombay is 250ms from New York in the new world order" - Alan Cox
| Damien Miller - http://www.mindrot.org/
| Email: djm@mindrot.org (home) -or- djm@ibs.com.au (work)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4gQlFormJ9RG1dI8RAny1AKCQCuc4ZwJ7Tjvnm6L721C4rWPVUQCg3l6I
cGfjBX6gO+uyZ6ZQhQwplQk=
=tKZF
-----END PGP SIGNATURE-----
Re: Mostly good news on the NeXT front. [ In reply to ]
On Sun, 16 Jan 2000, Damien Miller wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 12 Jan 2000, Jim Knoble wrote:
>
> > Ben, does NeXT have setenv()? If it does, you might be able to get
> > away with making a wrapper that uses either putenv() or setenv(),
> > depending on what's available. That would be much better than trying
> > to use glibc code.
>
> I have a replacement setenv which uses putenv already in bsd-misc.c.
>
I think you mean a putenv() that uses setenv() =) putenv() is posix where
setenv() was done pre-posix.=)

> It would be amusing to have to do the reverse as well.
>
There are some OSes that lack both.

BTW.. all my NeXT patchs will be delayed since I have to redo my NeXT box
and move it up to 4.2 to start setting it up for my website. So hopefully
I'll have that done in a few days.