Re: [9fans] pls. HELP porting problem

Re: [9fans] pls. HELP porting problem

[Aharon Robbins]

> in a similar way, one has been able to write
> 	p->f(args)
> rather than
> 	(*p->f)(args)
> for quite some time.

I think this actually worked in the V7 C compiler and PCC, no?

> perhaps it's not in the standard!

It is.  I think maybe even since 1989.

Arnold

Re: [9fans] pls. HELP porting problem

[Bruce Ellis]

PCC had a particularly aggressive disregard for indirections
in such cases.  if 'f' was a pointer to a function then ...

f();
(*f)();
(***************************f)();

produced the same code and no diagnostics.

brucee

On 4/29/05, Aharon Robbins <arnold@skeeve.com> wrote:
> > in a similar way, one has been able to write
> >       p->f(args)
> > rather than
> >       (*p->f)(args)
> > for quite some time.
> 
> I think this actually worked in the V7 C compiler and PCC, no?
> 
> > perhaps it's not in the standard!
> 
> It is.  I think maybe even since 1989.
> 
> Arnold

Re: [9fans] pls. HELP porting problem

[rog]

> PCC had a particularly aggressive disregard for indirections
> in such cases.  if 'f' was a pointer to a function then ...
> 
> f();
> (*f)();
> (***************************f)();

surely this is inevitable if f ≡ &f ?

Re: [9fans] pls. HELP porting problem

[Bruce Ellis]

i would never have thought to put in a while loop there.
must have *fixed* some *bug*.  there is no justification
for this behaviour.  if 'f' is of type ptr to fn, then *f is of
type fn ... and it is an expression not a name.  **f should
be illegal etc etc.

brucee

On 4/30/05, rog@vitanuova.com <rog@vitanuova.com> wrote:
> > PCC had a particularly aggressive disregard for indirections
> > in such cases.  if 'f' was a pointer to a function then ...
> >
> > f();
> > (*f)();
> > (***************************f)();
> 
> surely this is inevitable if f ≡ &f ?

Re: [9fans] pls. HELP porting problem

[C H Forsyth]

as i recall, this and several other peculiar effects
were the consequence of the process
by which the tree was rewritten.
it was along these lines.  (i could of course go
off and look at the source but is it worthwhile?)
you might have thought it would leave the types
alone and then when pointer-to-function appeared
as the type of an expression to which () was applied
it would insert a dereference.
but instead it applied the f to &f transformation
so *****f involved not a while loop but repeatedly
introducing &f from the bottom of the tree and having
adjacent *& cancel out (similarly, &*).  thus
	******f
	******&f
	*****f
	*****&f
	****f
	****&f
	***f
etc (i might have got the wrong number of * at some points)

little fleas indeed!

Re: [9fans] pls. HELP porting problem

[Bruce Ellis]

you'd only notice it if you wanted it to do the right thing
for ptr to ptr to fn etc.

brucee

On 4/30/05, C H Forsyth <forsyth@vitanuova.com> wrote:
> as i recall, this and several other peculiar effects
> were the consequence of the process
> by which the tree was rewritten.
> it was along these lines.  (i could of course go
> off and look at the source but is it worthwhile?)
> you might have thought it would leave the types
> alone and then when pointer-to-function appeared
> as the type of an expression to which () was applied
> it would insert a dereference.
> but instead it applied the f to &f transformation
> so *****f involved not a while loop but repeatedly
> introducing &f from the bottom of the tree and having
> adjacent *& cancel out (similarly, &*).  thus
>        ******f
>        ******&f
>        *****f
>        *****&f
>        ****f
>        ****&f
>        ***f
> etc (i might have got the wrong number of * at some points)
> 
> little fleas indeed!
> 
>

Re: [9fans] pls. HELP porting problem

[Brantley Coile]

> I think this actually worked in the V7 C compiler and PCC, no?
It did.

  Brantley

Re: [9fans] pls. HELP porting problem

[Ah Q]

On 4/29/05, Brantley Coile <brantley@coraid.com> wrote:
> > I think this actually worked in the V7 C compiler and PCC, no?
> It did.

I tried this with V7 on simh.

$ ed g.c
?g.c
a
main(){struct{int(*f)();}*s; s->f();}
.
w
38
!cc g.c
g.c:1: Call of non-function
!
!pcc g.c
g.c
"g.c", line 1: compiler error: no table entry for op UCALL
!
s/s->f/(*&)/p
main(){struct{int(*f)();}*s; (*s->f)();}
w
41
!cc g.c
!

[9fans] killing none's process

[arisawa]

Hello,

Now any user on cpu server can become "none".
Let alice be one of users and execute:
	listen1 someaddr /bin/somecmd
the process will be something like:
--rw-r----- p 0 none bootes   0 Apr 14 12:00 /proc/74/ctl
then how alice can kill the process?
(note that "none" cannot kill any other process)

Thanks

Kenji Arisawa

Re: [9fans] killing none's process

[Russ Cox]

> then how alice can kill the process?

she can't.  only hostowner can kill the process.

russ

Re: [9fans] pls. HELP porting problem

[Charles Forsyth]

>>!pcc g.c
>>g.c
>>"g.c", line 1: compiler error: no table entry for op UCALL

i don't know about the pdp11 but it worked in the other
PCCs because i used it extensively to do modules.