Re: [9fans] pptp.c install failed

Re: [9fans] pptp.c install failed

[Russ Cox]

you shouldn't have to run ipconfig.  just do

ip/pptp [-s user:password] 1.2.3.4

where 1.2.3.4 is your pptp server.
it sets up the interface for you.

netstat -i

should show it.

russ

[9fans] pptp testing (was pptp.c install failed)

[William S .]

I hope I am not missing something simple here.
I have been able to connect to my adsl via
FreeBSD so I know the isdn modem works. (Alcatel).


term% ip/pptp 10.0.0.138
fatal: dial net!10.0.0.138!pptp: fd out of range or not open
term%

On Mon, Nov 12, 2001 at 04:49:28PM -0500, Russ Cox wrote:
> you shouldn't have to run ipconfig.  just do
>
> ip/pptp [-s user:password] 1.2.3.4
>
> where 1.2.3.4 is your pptp server.
> it sets up the interface for you.
>
> netstat -i
>
> should show it.

Re: [9fans] pptp.c install failed

[William S .]

OK, I applied the changes as you specified below
and it installed. However, when I ran pptp
this happened:


term% ip/ipconfig ether /net/ether0 10.0.0.150 255.255.255.0
ip/ipconfig: binding device: dial 0x800 failed
term%

Is something configured incorrectly that I need to
change?

Thank you,

Bill

On Sun, Nov 11, 2001 at 03:35:38PM -0500, Russ Cox wrote:
> > pptp.c:92 function args not checked: threadnonotes
>
> threadnonotes is in the 03270425a update.
>
> > pptp.c:671 name not declared: ERRMAX
> > pptp.c:671 array size must be a positive constant
> > pptp.c:674 function args not checked: rerrstr
>
> sorry.  i was using a new interface.
> change it to e[ERRLEN] and rerrstr(e) and
> add the function
>
> void
> rerrstr(char *buf)
> {
> 	char tmp[ERRLEN];
>
> 	errstr(tmp);
> 	memmove(buf, tmp, ERRLEN);
> 	errstr(tmp);
> }
>
> before there.
>
> russ

Re: [9fans] pptp.c install failed

[Boyd Roberts]

Scott Schwartz wrote:
> C needs a counted array type, but until then we shouldn't
> cut corners.

No, C needs to be left alone.  Use limbo.

Re: [9fans] pptp.c install failed

[Dan Cross]

In article <20011111211751.23249.qmail@g.bio.cse.psu.edu> you write:
>C needs a counted array type

I disagree.  What we need is a new systems programming language that
includes a first-class string type that can grow dynamically.  Limbo
does this, but I don't think it goes far enough in other areas
(functions should be first-class, too, and where's my generic
dictionary?  If I ever have to code another set of freakin' hash table
routines...  I mean come on, that's not skill, it's tedium).

C is *really great* for what it does, but all too often it becomes the
language of choice when it shouldn't be.  If Inferno taught us nothing
else, it's that it needn't be a one-man game.  Large chunks of the
Inferno kernel are written in C, but all of the user-land stuff is done
in Limbo.  If we could take that concept of a two-man game and apply it
to Plan 9, we'd have an incredibly powerful system (but be even further
marginalized).

I guess what I'm really looking for is something like ``Limbo vs. ML''
meets ``?[cl]'' to replace C at the user level.

	- Dan C.

Re: [9fans] pptp.c install failed

[Russ Cox]

> Why not ``rerrstr(char *buf, int size)''?
> Or even ``rerrstr(Str buf)''?
>
> C needs a counted array type, but until then we shouldn't
> cut corners.

As part of the 9P2000 changes, we fixed both errstr and
rerrstr as you suggest:

	int errstr(char *err, uint nerr)
	void rerrstr(char *err, uint nerr)

ERRMAX takes the place of ERRLEN, but it is a convention
rather than a specification: if you use one that is too big
or too small, the safety of your program isn't put in jeopardy.

Thus the code in question originally read:

	void
	ewrite(int fd, void *buf, int nbuf)
	{
		char e[ERRMAX], path[64];

		if(write(fd, buf, nbuf) != nbuf){
			rerrstr(e, sizeof e);
			strcpy(path, "unknown");
			fd2path(fd, path, sizeof path);
			myfatal("write %d to %s: %s", nbuf, path, e);
		}
	}

which I think you wouldn't have any problems with.

I did think about posting an rerrstr(char*, uint), but
our rerrstr uses utfecpy to make sure it truncates at
a character boundary, and that function is post-distribution
too, so I stopped the cascade by assuming ERRLEN: since
the distribution errstr already does it, I don't see a problem
doing it in other places until we get a proper distribution out.

Russ

Re: [9fans] pptp.c install failed

[Scott Schwartz]

> rerrstr(char *buf)

Why not ``rerrstr(char *buf, int size)''?
Or even ``rerrstr(Str buf)''?

C needs a counted array type, but until then we shouldn't
cut corners.

Re: [9fans] pptp.c install failed

[Russ Cox]

> pptp.c:92 function args not checked: threadnonotes

threadnonotes is in the 03270425a update.

> pptp.c:671 name not declared: ERRMAX
> pptp.c:671 array size must be a positive constant
> pptp.c:674 function args not checked: rerrstr

sorry.  i was using a new interface.
change it to e[ERRLEN] and rerrstr(e) and
add the function

void
rerrstr(char *buf)
{
	char tmp[ERRLEN];

	errstr(tmp);
	memmove(buf, tmp, ERRLEN);
	errstr(tmp);
}

before there.

russ

[9fans] pptp.c install failed

[William S .]

[-- Attachment #1: Type: text/plain, Size: 111 bytes --]

I attempted to install pptp.c as below but
it failed. Any way to make it install?

Bill
Amsterdam, NL



[-- Attachment #2: error.txt --]
[-- Type: text/plain, Size: 289 bytes --]

term% mk pptp.install
8c -FVw pptp.c
pptp.c:92 function args not checked: threadnonotes
pptp.c:671 name not declared: ERRMAX
pptp.c:671 array size must be a positive constant
pptp.c:674 function args not checked: rerrstr
mk: 8c -FVw pptp.c  : exit status=rc 2929:8c 2931:error
term%