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

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

[rob pike, esq.]

for(what i want){
	do(what is right);
}until(all is done);

Then
	goto start;
and begin again.

Now *that's* a good language.

-rob

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.

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

[Douglas A. Gwyn]

arisawa@ar.aichi-u.ac.jp wrote:
> g=bffffc7c

Well, yeah, it obviously has to be allocated on either the stack or
the heap.  Heap allocation requires cleanup a la C++ destructor
while the stack cleanup is automatic.  Note that GNU seems to like
to use alloca also, perhaps for a similar reason.

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

[forsyth]

in some email, mike haertel pointed out that i was probably
making an extra assumption that gcc was not, namely that
my compiler was compiling all the code in the system, and
thus had control over all the interfaces, and he's right, i was.
of course, i then considered some exotic ways round that
but things were getting out of hand, so i stopped.

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?

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

> > Why not just get the compiler to generate the assembly language
> > for you.
> 
> My heart wasn't into it.
> 
> > 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.
> 
> Yeah, I'm running the ast-optimiser-branch gcc by default, and it does
> use trampolines.  I think it's quasi- based on gcc 3.0.
> 
> Before I go on another wild goose chase, what version specifically
> do you mean by "current"?
> 
Sorry - I should really have said 'more current' or 'recent'. It was
SuSE Linux 7.3, which comes with gcc-2.95.3-124

As I have since learned, a call to the nested function via a pointer
does indeed generate the jump to code on the stack....

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

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

[forsyth]

>>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...

it's a gcc-specific extension (certainly implemented THAT way).

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

it's not the normal frame pointer but a static link pointer that
allows the nested function's code to find the right frame instance for
accessing variables in the lexically-containing function.  it's
because the implementation uses a static link that it has a problem.
there is another technique that wouldn't.  the dragon book has a
reasonable discussion of the alternatives but doesn't actually discuss
the variant that could have been used here to avoid the need for the
trampoline crud (although it mentions it in a throwaway remark).

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

[David Gordon Hogan]

> 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...

Nested functions are a GNU extension.  I'd recommend pretending
that they don't exist as much as feasibly possible.

I don't have that option, due to the work that I'm doing.  But, if you're
writing new code, just don't use them and everything will be fine...

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

[David Gordon Hogan]

> Why not just get the compiler to generate the assembly language
> for you.

My heart wasn't into it.

> 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.

Yeah, I'm running the ast-optimiser-branch gcc by default, and it does
use trampolines.  I think it's quasi- based on gcc 3.0.

Before I go on another wild goose chase, what version specifically
do you mean by "current"?

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

[Digby Tarvin]

Thanks - I guess that confirms it does what I thought.

Are there any good papers on this sort of stuff, or does one
just have to wade through the source code?

Any recomendations on a worthy successor to the K&R book as a
good reference on the current state of the art of the language...?

Regards,
DigbyT

> it only uses the trampoline code when you call g indirectly through
> a function pointer.  if you call it directly it can provide the static link
> itself without that fuss.   when you create a function pointer to g,
> as in the call to printf, it does generate code onto the stack that
> loads the static link register then enters g.
> 	leal -16(%ebp),%eax
> 	movl $g.9-10,%edx
> 	movb $185,(%eax)
> 	movl %ebp,1(%eax)
> 	movb $233,5(%eax)
> 	subl %eax,%edx
> 	movl %edx,6(%eax)
> that's the generation on the fly of the trampoline code.
> note the movl %ebp,1(%eax), which stores the current frame pointer
> as a literal in the generated code.
> the `function pointer' that is later passed to printf is the address of
> -16(%ebp) [offsets might be different in your case], which when
> called will load the literal, and enter g with a pc-relative reference
> (i think that's about right).
> 
> you'd need to flush the cache(s) on some architectures, which is
> tricky when it's a privileged operation.
> 
> the problem it is trying to solve is to get the right value for the static link register,
> without passing the required value along with the function pointer as a pair.
> providing the right value for the static link register is
> easiest to do if it doesn't exist.  there are several
> approaches to implementing displays, and one of them allows nested
> function pointers as a single word but without this crud.
> 
> all these implementations of nested functions in C go sadly wrong if
> you call a nested function indirectly when it has gone out of scope.
> 
> 


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

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?

[forsyth]

it only uses the trampoline code when you call g indirectly through
a function pointer.  if you call it directly it can provide the static link
itself without that fuss.   when you create a function pointer to g,
as in the call to printf, it does generate code onto the stack that
loads the static link register then enters g.
	leal -16(%ebp),%eax
	movl $g.9-10,%edx
	movb $185,(%eax)
	movl %ebp,1(%eax)
	movb $233,5(%eax)
	subl %eax,%edx
	movl %edx,6(%eax)
that's the generation on the fly of the trampoline code.
note the movl %ebp,1(%eax), which stores the current frame pointer
as a literal in the generated code.
the `function pointer' that is later passed to printf is the address of
-16(%ebp) [offsets might be different in your case], which when
called will load the literal, and enter g with a pc-relative reference
(i think that's about right).

you'd need to flush the cache(s) on some architectures, which is
tricky when it's a privileged operation.

the problem it is trying to solve is to get the right value for the static link register,
without passing the required value along with the function pointer as a pair.
providing the right value for the static link register is
easiest to do if it doesn't exist.  there are several
approaches to implementing displays, and one of them allows nested
function pointers as a single word but without this crud.

all these implementations of nested functions in C go sadly wrong if
you call a nested function indirectly when it has gone out of scope.

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]

> 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?

[forsyth]

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

with the help of the Usenix paper about it, i understand now.  oh
dear!  he was trying to add it subject to a particular implementation
constraint: that void* could accept a function pointer and still be
one word.  he missed a way of implementing one of the techniques that
he does mention (but only in passing), and so goes to all that acrobatic
effort.  Dijkstra rules!   unless of course, i've missed something.
well, Dijkstra still rules.

on the other hand, what do i know about AI?

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

[arisawa]

>Nope.  All you have to do is overwrite return addresses and
>data in the stack.  Many programs have code that can be twisted
>to your own ends if you just call it with the right parameters.
Hmm...
I have some questions.
(1) Is the following program one of `Many programs'?
#include <stdio.h>
int main(){
    char buf[BUFSIZ];
    gets(buf);
    puts(buf);
}

(2) Does your strategy require source or binary code
of the target to execute execl() ?
(I cannot imagine how to find the location of execl())

Kenji Arisawa

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

[Lucio De Re]

On Thu, Jul 18, 2002 at 03:24:33PM -0400, David Gordon Hogan wrote:
> 
> > That's where Microsoft's "security by obscurity" argument would
> > acquire validity, isn't it?
> 
> I think they're banking on evolutionary pressure against smart
> people eventually wiping out all of the potential hackers.

Don't fool yourself.  They're _applying_ social engineering techniques
to supplement any weakness in evolutionary pressure.  Presenting
compelling arguments against publication of source and demonising
published source as contributing to terrorism is one way of producing
uneducated acolytes.

++L

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?

[arisawa]

Hello,

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

[arisawa@vega tmp]$ cat>a.c
#include <stdio.h>
int foo(){;}

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);
}

int main(){
        bar();
}
[arisawa@vega tmp]$ gcc a.c
[arisawa@vega tmp]$ ./a.out
foo=80483c8
bar=80483dc
i=bffffc8c
g=bffffc7c
h=bffffc88
[arisawa@vega tmp]$

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

[David Gordon Hogan]

> That's where Microsoft's "security by obscurity" argument would
> acquire validity, isn't it?

I think they're banking on evolutionary pressure against smart
people eventually wiping out all of the potential hackers.

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

[forsyth]

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

actually, the thing i don't understand is why nested procedures
required putting code on the stack.  i've implemented them a few
times, even with closures, and i didn't need to do that.
where did i do wrong?  perhaps it was just a display
of technical prowess,  or does gcc also not do that, really.

[-- Attachment #2: Type: message/rfc822, Size: 2380 bytes --]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] useful language extension, or no?
Date: Thu, 18 Jul 2002 14:21:07 GMT
Message-ID: <3D36CB17.D4FEC4C0@null.net>

Lucio De Re wrote:
> The usual buffer overflow problem: override the stack limits, wreck
> the return address, execute the remainder (by returning to it).

But that is independent of whether the original program generated
code on the stack.  It's merely a matter of whether the stack lies
in an address space compatible with instruction space.  On a split
I/D-space system, or one where pages do support X bits, code cannot
run on the stack.

Anyway, buffer overruns would be a security problem anyway, even
if one could not add code, because state variables can be changed
in unplanned ways.  One of the early such exploits merely set the
"password was valid" flag.

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

[Lucio De Re]

On Thu, Jul 18, 2002 at 07:50:28AM -0700, Mike Haertel wrote:
> 
> Nope.  All you have to do is overwrite return addresses and
> data in the stack.  Many programs have code that can be twisted
> to your own ends if you just call it with the right parameters.
> Admittedly this requires doing a little more homework than
> just putting executable code in the stack.  But making the
> stack non-executable is not a way of "locking the barn door"
> by any means.  It's more like just closing the barn door and
> hoping nobody will notice the padlock is missing.

That's where Microsoft's "security by obscurity" argument would
acquire validity, isn't it?

++L

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

[Lucio De Re]

On Thu, Jul 18, 2002 at 02:21:07PM +0000, Douglas A. Gwyn wrote:
> 
> Anyway, buffer overruns would be a security problem anyway, even
> if one could not add code, because state variables can be changed
> in unplanned ways.  One of the early such exploits merely set the
> "password was valid" flag.

A valid point (it's sendmail you seem to be referring to).  I've often
given only superficial attention to these issues and I'm pleased to
pick up a little more understanding about them (and, yes, I do label
myself a "security consultant" :-)

++L

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

[Mike Haertel]

>I neglected to mention that locking the stack against execution is a
>way of locking the barn door, programmers _ought_ to know better, but
>the tools to _do_ better haven't been available until recently.

Nope.  All you have to do is overwrite return addresses and
data in the stack.  Many programs have code that can be twisted
to your own ends if you just call it with the right parameters.
Admittedly this requires doing a little more homework than
just putting executable code in the stack.  But making the
stack non-executable is not a way of "locking the barn door"
by any means.  It's more like just closing the barn door and
hoping nobody will notice the padlock is missing.

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

[Douglas A. Gwyn]

Lucio De Re wrote:
> The usual buffer overflow problem: override the stack limits, wreck
> the return address, execute the remainder (by returning to it).

But that is independent of whether the original program generated
code on the stack.  It's merely a matter of whether the stack lies
in an address space compatible with instruction space.  On a split
I/D-space system, or one where pages do support X bits, code cannot
run on the stack.

Anyway, buffer overruns would be a security problem anyway, even
if one could not add code, because state variables can be changed
in unplanned ways.  One of the early such exploits merely set the
"password was valid" flag.

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

[Richard Miller]

> for(what i want){
> 	do(what is right);
> }until(all is done);
> 
> Then
> 	goto start;
> and begin again.
> 
> Now *that's* a good language.
> 
> -rob

Once again Rob's satire underestimates the horror of the real world.
See, for example, the COBOL "PERFORM" statement:

 http://www.helsinki.fi/atk/unix/dec_manuals/cobv27ua/6296-88.gif

-- Richard

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

[Lucio De Re]

On Thu, Jul 18, 2002 at 12:19:31PM +0200, Lucio De Re wrote:
> > 
> > How is that a security problem?  The stack is accessible only
> > under program control, and a programmer can do whatever he
> > wants anyway.
> 
> The usual buffer overflow problem: override the stack limits, wreck
> the return address, execute the remainder (by returning to it).
> 
I neglected to mention that locking the stack against execution is a
way of locking the barn door, programmers _ought_ to know better, but
the tools to _do_ better haven't been available until recently.

One wonders if one should be grateful for script kiddies :-)

++L

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

[Lucio De Re]

On Thu, Jul 18, 2002 at 09:51:14AM +0000, Douglas A. Gwyn wrote:
> 
> arisawa@ar.aichi-u.ac.jp wrote:
> > By the way, GNU C compiler allows nested function definition.
> > To do that, some of machine codes are put into stack.
> > It may cause security problem to be executed machine codes
> > in statck.
> 
> How is that a security problem?  The stack is accessible only
> under program control, and a programmer can do whatever he
> wants anyway.

The usual buffer overflow problem: override the stack limits, wreck
the return address, execute the remainder (by returning to it).

++L

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

[Douglas A. Gwyn]

arisawa@ar.aichi-u.ac.jp wrote:
> By the way, GNU C compiler allows nested function definition.
> To do that, some of machine codes are put into stack.
> It may cause security problem to be executed machine codes
> in statck.

How is that a security problem?  The stack is accessible only
under program control, and a programmer can do whatever he
wants anyway.

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

[Ronald G Minnich]

On Thu, 18 Jul 2002 arisawa@ar.aichi-u.ac.jp wrote:

> Is it unavoidable machine codes in stack are executable?

your architecture has to support r,w,x on segments. then the OS has to
actually make that work. Most OSes I've seen always set x on all segments,
including stack. It's not even possible to do things otherwise on many of
them.

Does plan9 have x-only and r-only and rw-only segments in the VM system? I
was pretty sure it did not.

I got into fruitless argument with an architecture guy about the value of
x bits in the VM system. His argument was that it was a bad idea for
performance. I doubt even in the x86 that it is solid and well-tested, but
who knows.

ron

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

[arisawa]

Hello,

>        for (x = 1 => { /* initialisation */ };
>                x < num => { /* termination */ };
>                x++ => { /* body */ };
>        );
>
Why not ?:
	x=1;
	while(x<num){
		x++;
	}

By the way, GNU C compiler allows nested function definition.
To do that, some of machine codes are put into stack.
It may cause security problem to be executed machine codes
in statck.
Some years ago I tested Plan9 (2nd edition) whether stack of
Plan9 are executable or not. The answer was YES.
So I have a qauestion:
Is it unavoidable machine codes in stack are executable?

My memory is faded. Forgive me if I make a mistake.

Kenji Arisawa

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

[Fariborz (Skip) Tavakkolian]

In a strange twist, there is a C like language called Pike that
has experimented with all sorts of things like this. It has all kinds of 
neat and quirky things; like for example defining inline functions
right in the parameter list of a function call.  That might be a good place
for these types of experiments.   I was intrigued by it, but then Limbo
came along.

BTW, the Roxen web server is written in Pike.

At 03:33 PM 7/17/2002 +0200, Lucio De Re wrote:
>Just as I was getting brave enough to suggest:
>
>        for (x = 1 => { /* initialisation */ };
>                x < num => { /* termination */ };
>                x++ => { /* body */ };
>        );
>
>(syntactic spices to taste) ...

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

[Lucio De Re]

On Wed, Jul 17, 2002 at 08:12:14AM -0400, Sam wrote:
> 
> Methinks we can let this poor atend be.  We've beaten it
> enough ... he'll be sore for weeks.  Not only is it not
> worth modifying *any* language for, it's not worth putting
> into a new one.  I'm still glad I brought it up; this
> has been a good thread.
> 
Just as I was getting brave enough to suggest:

	for (x = 1 => { /* initialisation */ };
		x < num => { /* termination */ };
		x++ => { /* body */ };
	);

(syntactic spices to taste) ...

++L

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

[Ian Broster]

 
> for(i=0; i<NELS; i++) {
> 	// do some stuff
> }
> atend ..

I'm sure someone must have done something obfuscated with a #define
before? 

How about:  ;-)

#define forend(init,cond,inc,block,cont) for(init; cond || (cont,0) ;inc) block

	forend (i=0, i<5, i++, {
		printf("%d\n",i);
	}, printf("Loop terminated\n"))
	
which gives:

	for(i=0; i<5 || ( printf("Loop terminated\n") ,0); i++){
		printf("%d\n",i);
	}

;-) ian

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

[Sam]

> #define forend(init,cond,inc,block,cont) for(init; cond || (cont,0) ;inc) block
>
> 	forend (i=0, i<5, i++, {
> 		printf("%d\n",i);
> 	}, printf("Loop terminated\n"))

Dear.  Lord.

Methinks we can let this poor atend be.  We've beaten it
enough ... he'll be sore for weeks.  Not only is it not
worth modifying *any* language for, it's not worth putting
into a new one.  I'm still glad I brought it up; this
has been a good thread.

So, back to spaces in filenames ... :-X

Sam

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

[Douglas A. Gwyn]

forsyth@vitanuova.com wrote:
> in the case of Lock, it's easy to see that we could do without:
> just requires
>         lock(&t->l);
> instead of
>         lock(t);
> as in Plan 9.
> the advantage of the latter, however, is that it is clear and readable,
> not that it saves typing.

Indeed, when I was trying to track down a bug in floppy booting
(with mixed drive types), I wasted some time thinking I had found
the bug in one such instance, having temporarily forgotten about
that Plan 9 C extension.  I personally prefer the &t->l as saying
exactly what is meant, instead of invoking some behind-the-scene
mapping.  But I think it was an interesting experiment anyway.

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

[Douglas A. Gwyn]

presotto@plan9.bell-labs.com wrote:
> #define sa_len          sa_union.sa_generic.sa_len2

A lot of that kind of thing was due to changing an interface to be
more general but wanting to avoid having to edit existing code that
was written before the data type changed.  This kind of thing dates
back to 7th Edition Unix time functions, where the &l in the 7th
Edition function interface corresponds to 6th Edition's pointer to
an array of two ints.

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

[William Josephson]

In article <6333e0a01e113662f55923372089278a@plan9.bell-labs.com>, presotto@plan9.bell-labs.com wrote:
 
>> Including tuples (perhaps as an instance of nameless structs) would
>> simplify many interfaces, right? that's one thing I learned using
>> Limbo.
> 
> This I wouldn't mind seeing.  I really miss limbo tuples.  Of course,
> I miss garbage collection too.

Tuples are one of the things I miss most in C, too.
But garbage collection for dns is a close second :-/

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

[Steve Kilbane]

> Suppose I'm not saying "why," but "why not."  IMO it's cleaner

I disagree. It's considerably more ambiguous. Your loop continuation
condition (i<NELS) may be failed by considerably more cases
than your trailing condition (i==NELS). What happens if your loop
body does "i=NELS+1"? What if your "i++" was actually something
like "i=arr[i]"? What if your continuation condition was
"i<NELS && j<NELS2"?

C's "for" is not like Pascal's FOR.

> and
> quite possibly more efficient

The pros and cons have already been discussed. I'd just like to
note that there's no particularly compelling reason why it would
generate different code from that which used the idiom. A good
optimiser would render them into the same internal form anyway.

"A good optimiser" is a subjective term, and Plan 9's C optimising
has already been discussed recent (Summary: it's good enough that
there are more important/interesting/useful things to work on),
but the point stands.

steve

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

[presotto]

> You're going to have to do better than that.  Simply
> pulling the 'ole "I'm overly negative and as a result most
> people avoid confrontation with me" isn't going to cut it.
> 

The unnamed types and inheritance are indeed syntactic sugar.  It did have
the useful side effect of reducing typing.  If any of you remember BSD, you'ld
remember cruft like

#define sa_len		sa_union.sa_generic.sa_len2
#define sa_family	sa_union.sa_generic.sa_family2
#define	sa_data		sa_union.sa_generic.sa_data2

from /usr/include/sys/socket to avoid typing infinitely
long names.  The unnamed types saves us a lot more than
a few characters here and there.  It saves us from such
#defines which have a bad habit of getting out of sync
with the things they're working around.

The added inheritance saves a fair amount, though not all,
of the casts and void*'s that we used to live with.  These
blind conversions are very error prone.  I'ld rather the
compiler catch my errors than go at it during run time.

> 
> Anyone else have an opinion on this ... specifically the guys/gals
> at the labs, since without their consent tool changes doubtfully
> become realised?

`atend' does have the advantage of catching some mistakes.  However,
it doesn't really catch any errors that I typically make so I'm
less sanguine about changing the language for it.

> Including tuples (perhaps as an instance of nameless structs) would
> simplify many interfaces, right? that's one thing I learned using
> Limbo.

This I wouldn't mind seeing.  I really miss limbo tuples.  Of course,
I miss garbage collection too.

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

[Howard Trickey]

> Anyone else have an opinion on this ... specifically the guys/gals
> at the labs, since without their consent tool changes doubtfully
> become realised?

OK, you asked for it.

I'm completely in agreement with Rob.
There should be a high bar for adding language extensions
(each one makes it harder to port code that uses them).
The "atend" thing is very far below the bar.
It is arguable whether the anonymous type thing was above
the bar, but it was certainly a lot higher.  The latter
lets the compiler do type checking for you in a common
situation (one where you might be using inheritance in
another language, as Rob pointed out).

- Howard Trickey

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

[forsyth]

>>Why was it worthwhile to change the language in this respect,
>>for the idiom of "always having to make sure the lock is the
>>first item in the structure for pointer coersion is a pain?"

because with ken's extension, it needn't be the first element,
and it provides type checking that would be suppressed
by the explicit cast required for the `first item' approach.

in the case of Lock, it's easy to see that we could do without:

	typedef struct Thing Thing;
	struct Thing{
		int	a;
		Lock	l;
	};

just requires
	lock(&t->l);
instead of
	lock(t);
as in Plan 9.

the advantage of the latter, however, is that it is clear and readable,
not that it saves typing.  in fact it does save typing, but that's
a side effect.

it's also a little more subtle in the case of bio (say).

in fact, C provides just what you want to save the ugly
extra comparison: functions with early return.

>>You're going to have to do better than that.  Simply
>>pulling the 'ole "I'm overly negative and as a result most
>>people avoid confrontation with me" isn't going to cut it.

overly negative?  surely no one negative and pessimistic
would bother to start thinking about writing a system, let
alone actually doing it.   surely doing something constructive
is a truly positive act!

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

[rob pike, esq.]

> What about the promotion of a structure from itself
> to one of its members in a function call simply because
> it makes locking a structure easier?  Surely passing in
> a pointer to a function and having the in-func pointer completely
> different violates some standard of programming languages.

It's called inheritance.

> Why was it worthwhile to change the language in this respect,
> for the idiom of "always having to make sure the lock is the
> first item in the structure for pointer coersion is a pain?"

Yes.

-rob

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

[Boyd Roberts]

Sam wrote:

>just equates to
>
>for(...) {
>
>} atend
>	;
>

python lets you do this:

    for v in ...:
        if v == ...:
           break
    else:
        atend

So the else part is executed should the loop terminate normally (no break is
executed or the loop body is never entered).

It can be applied to while loops too.

I'm not sure whether it's a great idea but it did save a 'match' variable
when I was trying to match one 'condition' in a list of 'conditions'.

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

[Sam]

> OK, you asked for it.

In fact, I decidedly did.

>
> I'm completely in agreement with Rob.
> There should be a high bar for adding language extensions
> (each one makes it harder to port code that uses them).
> The "atend" thing is very far below the bar.
> It is arguable whether the anonymous type thing was above
> the bar, but it was certainly a lot higher.  The latter
> lets the compiler do type checking for you in a common
> situation (one where you might be using inheritance in
> another language, as Rob pointed out).
>

Which I agree with.  I was looking for an answer, much like the
offspring who gets frustrated with the parent's "because I said so."

Thanks for the "input" vs. the "offput."

Sam

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

[rob pike, esq.]

> Suppose I'm not saying "why," but "why not."  IMO it's cleaner and
> quite possibly more efficient (without getting into a usec argument,
> please).  Do you disagree?

Yes.  The benefit is minor, too small to justify changing the language.
You're trying to formalize an idiom; just using the idiom suits me fine.

The type inclusion feature, I think, did a lot more, since it trigged type
conversion and promotion: a much bigger deal.

-rob

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

[Sam]

You're going to have to do better than that.  Simply
pulling the 'ole "I'm overly negative and as a result most
people avoid confrontation with me" isn't going to cut it.

Anyone else have an opinion on this ... specifically the guys/gals
at the labs, since without their consent tool changes doubtfully
become realised?

Sam

On Tue, 16 Jul 2002, rob pike, esq. wrote:

> > What about the promotion of a structure from itself
> > to one of its members in a function call simply because
> > it makes locking a structure easier?  Surely passing in
> > a pointer to a function and having the in-func pointer completely
> > different violates some standard of programming languages.
>
> It's called inheritance.
>
> > Why was it worthwhile to change the language in this respect,
> > for the idiom of "always having to make sure the lock is the
> > first item in the structure for pointer coersion is a pain?"
>
> Yes.
>
> -rob
>

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

[rob pike, esq.]

Saves you, what, 5 keystrokes?  Not too convincing.

-rob

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

[Sam]

Ok, I'll bite and play devil's advocate.

What about the promotion of a structure from itself
to one of its members in a function call simply because
it makes locking a structure easier?  Surely passing in
a pointer to a function and having the in-func pointer completely
different violates some standard of programming languages.

Why was it worthwhile to change the language in this respect,
for the idiom of "always having to make sure the lock is the
first item in the structure for pointer coersion is a pain?"

Sam

On Tue, 16 Jul 2002, rob pike,
esq. wrote:

> > Suppose I'm not saying "why," but "why not."  IMO it's cleaner and
> > quite possibly more efficient (without getting into a usec argument,
> > please).  Do you disagree?
>
> Yes.  The benefit is minor, too small to justify changing the language.
> You're trying to formalize an idiom; just using the idiom suits me fine.
>
> The type inclusion feature, I think, did a lot more, since it trigged type
> conversion and promotion: a much bigger deal.
>
> -rob
>

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

[Sam]

You're right, and the capability to do:

struct type {
	int a;
	int b;
};

struct type2 {
	type;
	int c;
	int d;
};

saves so many more strokes in itself *and must* be more efficient.

Suppose I'm not saying "why," but "why not."  IMO it's cleaner and
quite possibly more efficient (without getting into a usec argument,
please).  Do you disagree?

Sam

On Tue, 16 Jul 2002, rob pike, esq. wrote:

> Saves you, what, 5 keystrokes?  Not too convincing.
>
> -rob
>

[9fans] useful language extension, or no?

[Sam]

I find myself and others occasionally doing the following:

for(i=0; i<NELS; i++) {
	// do some stuff
	// do more stuff
}

if(i == NELS) {
	// do cleanup or something ...
	// typically it's "damn, it wasn't in the array, exit"
}

So what do 9'ers think about an extension to the for loop
like this:

for(i=0; i<NELS; i++) {
	// do some stuff
	// do more stuff
} atend {
	// ...
	// ...
}

where the code in atend is only executed if the end of the loop is
hit?  This wouldn't break existing code since the usual case of

for(...) {

}

just equates to

for(...) {

} atend
	;

and thusly the atend can be removed, and it would save an extra
comparison/branch sequence in the emitted code (it seems).

Looking forward to your thoughts!

Cheers,

Sam