Re: [9fans] INVESTMENT & ASSISTANCE

Re: [9fans] INVESTMENT & ASSISTANCE

[Digby Tarvin]

I normally feel obliged to report this sort of blatant fraud when
I receive it directly, but there isn't enough header information
when it comes via a list. Is someone taking care of it?

It always seems a little irresponsible to me to just install filters
and leave inexperienced net users to the mercy of the con men....

I would imagine that with the formidable combined expertise of the
subscribers on this list, you would have to be pretty stupid to spam
it.

Anybody got any good tips for effective ways to deal with spammers?
I am fequently frustrated by NICs that allow IP registrants to privide
false (or no) e-mail address with which to report abuse.

DigbyT

THOMAS  EDWARDS:
> From 9fans-admin@cse.psu.edu Sun Jun 16 21:38:46 2002
> Delivered-To: 9fans@cse.psu.edu
> From: "THOMAS  EDWARDS" <thomyeddy@yahoo.co.uk>
> To: 9fans@cse.psu.edu
> Subject: [9fans] INVESTMENT & ASSISTANCE
> STRICTLY CONFIDENTIAL & URGENT.
>
>  I am Mr, Thomas Edwards a native of Cape Town in
>  South Africa and I am an Executive Accountant with
>  the

etc.

--
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk

Re: [9fans] INVESTMENT & ASSISTANCE

[Scott Schwartz]

| I normally feel obliged to report this sort of blatant fraud when
| I receive it directly, but there isn't enough header information
| when it comes via a list. Is someone taking care of it?

Yeah, sometimes.  I also update the spam filters, where feasable.
That said, I don't think mailman strips the headers you need.  Just look
at the Received lines preceeding the ones for cse.psu.edu.

| Anybody got any good tips for effective ways to deal with spammers?

No, they've won.  What we need is an alternative email network that only
nice people are allowed to use, and meaningful punishment for abusers.
I see this as our chance to reintroduce bangpaths and uucp. :)

As a first approximation, we could set the 9fans list so that only
subscribers can post, but that would probably break the usenet gateway.

Re: [9fans] INVESTMENT & ASSISTANCE

[Lucio De Re]

On Sun, Jun 16, 2002 at 08:49:29PM -0400, Scott Schwartz wrote:
>
> | Anybody got any good tips for effective ways to deal with spammers?
>
> No, they've won.  What we need is an alternative email network that only
> nice people are allowed to use, and meaningful punishment for abusers.
> I see this as our chance to reintroduce bangpaths and uucp. :)
>
You may be joking, but I've been toying with the idea ever since the
Director of the Department of Communications here in South Africa
took it upon his department to take over management of the ZA DNS
namespace.  Was UUCP ever ported to Plan 9?  Hm, pathalias always
frightened me :-(

> As a first approximation, we could set the 9fans list so that only
> subscribers can post, but that would probably break the usenet gateway.

Unfortunately (but maybe not) you're right, the mail<->news gateway
would fail.  Again, that does not bother me, as I have no NetNews
access and prefer closed mailing lists anyway, but others will
understandably differ in opinion.

++L

Re: [9fans] INVESTMENT & ASSISTANCE

[presotto]

I agree, the spammers have won.

> As a first approximation, we could set the 9fans list so that only
> subscribers can post, but that would probably break the usenet gateway.

I agree that if we need to, that's a reasonable possibility.  I do it
with personal mail and it works quite well for me.  No spammer has
taken the trouble to add themselves to my list and no friend, no matter
how computer fearful, has failed to do it.  How does the
usenet gateway work?  Could we just add anything that comes from
it despite a subscriber filter?

We could also go to a moderator that cuts out obvious spam
but who has the time.

However, given the low rate of spammers we currently have, I
suggest just ignoring the problem for now and hitting 'd'
or whatever a few times a week.  We'll have plenty of motivation
to do something if things get noisier.

Re: [9fans] INVESTMENT & ASSISTANCE

[Russ Cox]

> I agree that if we need to, that's a reasonable possibility.  I do it
> with personal mail and it works quite well for me.  No spammer has
> taken the trouble to add themselves to my list and no friend, no matter
> how computer fearful, has failed to do it.

I hold the mail in a separate mailbox (using pipeto.sample-hold
rather than pipeto.sample in /sys/src/cmd/upas/filterkit)
and it also works quite well.  Once a day or two I run mail -f _held
and delete the spam.  I feel bad tossing mail back at people
and I'm on too many low-volume mailing lists that I've
forgotten about.

I also send mail from multiple places so occasionally I send
mail to someone and their response ends up in _held.
I'm much happier with that than having the response get
bounced.

Russ

Re: [9fans] INVESTMENT & ASSISTANCE

[Russ Cox]

> Unfortunately (but maybe not) you're right, the mail<->news gateway
> would fail.  Again, that does not bother me, as I have no NetNews
> access and prefer closed mailing lists anyway, but others will
> understandably differ in opinion.

Other things would break too.  For example most of the readers
on plan9.bell-labs.com aren't subscribed directly.
We have a local fan-out address that is subscribed.
And I should be able to post from any of my addresses,
etc. etc. etc.

Re: [9fans] useful language extension, or no?

[David Gordon Hogan]

>>or does gcc also not do that, really.
> Look bellow:

Interesting.  My guess is that it's creating a
trampoline on the stack, which calls the real
g(), which nm tells me is at:

080485a6 t g.0

Unfortunately gdb on the Linux server is unable to show
me the instructions:

Reading symbols from a.out...Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.

But a quick grep for "tramp" in the gcc source finds such
beauties as:

libgcc2.c:1639: /* Make stack executable so we can call trampolines on stack.

and (in function.c):

/* Return the address of the trampoline for entering nested fn FUNCTION.
   If necessary, allocate a trampoline (in the stack frame)
   and emit rtl to initialize its contents (at entry to this function).  */


...and that's about all that I have the stomach for
right now...

Re: [9fans] useful language extension, or no?

[Digby Tarvin]

> Interesting.  My guess is that it's creating a
> trampoline on the stack, which calls the real
> g(), which nm tells me is at:
> 
> 080485a6 t g.0
> Unfortunately gdb on the Linux server is unable to show
> me the instructions:
> 
Why not just get the compiler to generate the assembly language
for you.

It is interesting that the current compiler lets you do it (my old
BSD system won't swallow it) but I can't see any attempt to actually
execute any code on the stack.

For instance, adding code to actually call the function:
int bar(){
        int i;
        int g(){;}
        int h;
        printf("foo=%x\n",foo);
        printf("bar=%x\n",bar);
        printf("i=%x\n",&i);
        printf("g=%x\n",g);
        printf("h=%x\n",&h);
        g();
}

generates
		.
		.
        call printf
        addl $16,%esp
        movl %ebp,%ecx
        call g.6
.L3:
        movl %ebp,%esp
        popl %ebp
        ret

where g.6 is in the code segment:
g.6:
        pushl %ebp
        movl %esp,%ebp
        subl $24,%esp
        movl %ecx,-4(%ebp)
.L4:
        movl %ebp,%esp
        popl %ebp
        ret

and the address of the function is put on the stack, but not used
in the call:

bar:
        pushl %ebp
        movl %esp,%ebp
        subl $56,%esp
        leal -36(%ebp),%edx
        leal 15(%edx),%eax
        andb $240,%al
        movl $g.6,%edx
        leal 10(%eax),%ecx
        subl %ecx,%edx
        movb $185,(%eax)
        movl %ebp,1(%eax)
        movb $233,5(%eax)
        movl %edx,6(%eax)
        addl $-8,%esp
        pushl $foo
        pushl $.LC0
        call printf
		.
		.

This is assuming I am reading the Intel code correctly. I am much more
at home with Motorola or DEC assembly language, but I think these code
fragments seem pretty clear.

I don't really understand the need to have a pointer to the function
on the stack, but I am sure there is a good reason for it. Thre restricted
scope of the function name, which I guess could be useful, does not seem
to depend on it.

Regards,
DigbyT
-- 
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk

Re: [9fans] useful language extension, or no?

[Mike Haertel]

>I don't really understand the need to have a pointer to the function
>on the stack, but I am sure there is a good reason for it. Thre restricted
>scope of the function name, which I guess could be useful, does not seem
>to depend on it.

In order to call a lexically scoped nested function, a caller needs
two pieces of information:

	1.  the actual address address of the code

	2.  a pointer to the stack frame for the containing function,
	    sometimes called the static chain pointer.

A traditional C "pointer to function" is just (1) since there is no
containing function.

In order to make "pointer to nested function" have the same
representation as "pointer to top level function", GCC creates a
small bit of trampline code on the stack that sets up (2), then
jumps to (1).  Then when a pointer to the nested function is actually
needed, GCC passes out the pointer to the trampoline code.

The trampoline isn't needed when the call to the nested function is a
direct call within the scope of the parent function--it's only needed
when the nested function is being called via a function pointer from an
unknown scope.  So if you never take the address of a nested function,
GCC shouldn't generate any trampoline code.

The alternative to the trampoline would be for "pointer to function"
to become a two-word object, or a pointer to a two-word object, with a
changed calling sequence in either case.  This would be fine, the C
standard would certainly allow it, but it would be binary incompatible
with existing calling conventions in most systems.

Re: [9fans] useful language extension, or no?

[Digby Tarvin]

Ah - I see! It hadn't realised that the scope rules now included
that sort of nesting. When did that happen? I guess I am going to
have to trade in my much loved, dog eared K&R for a book on
standard C one of these days...

Presumably I need something along the lines of

  #include <stdio.h>
  int foo(int (*f)()) {
          (*f)();
  }
  
  int main() {
          int g(){; }
          foo(g);
  }

To see it used, producing:

foo:
        pushl %ebp
        movl %esp,%ebp
        subl $20,%esp
        pushl %ebx
        movl 8(%ebp),%ebx
        call *%ebx
.L2:
        movl -24(%ebp),%ebx
        movl %ebp,%esp
        popl %ebp
        ret

Presumably %esp is the stack pointer, %ebp is the frame pointer,
and %ebx is the a scratch register used for parameter passing
and jumping through to get to the trampoline. Makes me curious
about what the 'e' stands for - like I said, I am not an x86 expert...

This seems to require the somewhat less than transparent calling sequence:

main:
        pushl %ebp
        movl %esp,%ebp
        subl $40,%esp
        leal -28(%ebp),%edx
        leal 15(%edx),%eax
        andb $240,%al
        movl $g.6,%edx
        leal 10(%eax),%ecx
        subl %ecx,%edx
        movb $185,(%eax)
        movl %ebp,1(%eax)
        movb $233,5(%eax)
        movl %edx,6(%eax)
        addl $-12,%esp
        leal -28(%ebp),%edx
        leal 15(%edx),%eax
        andb $240,%al
        pushl %eax
        call foo
        addl $16,%esp
.L3:
        movl %ebp,%esp
        popl %ebp
        ret

Presumably $185 generates the instruction to load the frame pointer,
and $233 creates the jump to the actual function.

Thanks for the explanation. The level of knowledge on this list never
ceases to impress me...

Regards,
DigbyT

> In order to call a lexically scoped nested function, a caller needs
> two pieces of information:
> 
> 	1.  the actual address address of the code
> 
> 	2.  a pointer to the stack frame for the containing function,
> 	    sometimes called the static chain pointer.
> 
> A traditional C "pointer to function" is just (1) since there is no
> containing function.
> 
> In order to make "pointer to nested function" have the same
> representation as "pointer to top level function", GCC creates a
> small bit of trampline code on the stack that sets up (2), then
> jumps to (1).  Then when a pointer to the nested function is actually
> needed, GCC passes out the pointer to the trampoline code.
> 
> The trampoline isn't needed when the call to the nested function is a
> direct call within the scope of the parent function--it's only needed
> when the nested function is being called via a function pointer from an
> unknown scope.  So if you never take the address of a nested function,
> GCC shouldn't generate any trampoline code.
> 
> The alternative to the trampoline would be for "pointer to function"
> to become a two-word object, or a pointer to a two-word object, with a
> changed calling sequence in either case.  This would be fine, the C
> standard would certainly allow it, but it would be binary incompatible
> with existing calling conventions in most systems.
> 


-- 
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk

Re: [9fans] useful language extension, or no?

[Scott Schwartz]

| Ah - I see! It hadn't realised that the scope rules now included
| that sort of nesting. When did that happen? 

Never, it's a totally nonstandard gnu extension. :)

It's darn annoying that the actual C standard isn't freely available,
the way the corresponding Ada and Common Lisp standards are.

Re: [9fans] useful language extension, or no?

[Digby Tarvin]

> | Ah - I see! It hadn't realised that the scope rules now included
> | that sort of nesting. When did that happen? 
> 
> Never, it's a totally nonstandard gnu extension. :)
> 
In that case, I don't feel so bad about overlooking it.

> It's darn annoying that the actual C standard isn't freely available,
> the way the corresponding Ada and Common Lisp standards are.

Yes, that is a pain.

DigbyT
-- 
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk

Re: [9fans] useful language extension, or no?

[Ralph Corderoy]

Hi Mike,

> The alternative to the trampoline would be for "pointer to function"
> to become a two-word object, or a pointer to a two-word object, with a
> changed calling sequence in either case.  This would be fine, the C
> standard would certainly allow it, but it would be binary incompatible
> with existing calling conventions in most systems.

Under IBM's AIX a pointer to function is the address of three words.

    Entry point of function's code.
    Address of module's Table of Contents.
    Used by some languages' implementations, OCS Ada for one IIRC.

So they went for the `function pointer fits into long' solution to avoid
breakage.

Cheers,


Ralph.