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

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]

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
>

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

[9fans] presentation preparation

[Sam]

I'm working on a presentation and am
wondering what approach other 9'ers take
to preparing slides.  I'm thinking
a full screen page(1) would be sufficient
and I could use the extant doc prep
tools I'm becoming increasingly familiar
with.

Tips, tricks, and/or suggestions are welcomed.

Cheers,

Sam

Re: [9fans] presentation preparation

[Scott Schwartz]

| I could use the extant doc prep
| tools I'm becoming increasingly familiar
| with.

Not a Plan 9 specific answer, but...  I rather like latex with the
prosper package.  Ideally it is used to make pdf, and can take advantage
of acroread's features, but straight ps output should be usable.

Re: [9fans] presentation preparation

[andrey mirtchovski]

We were discussing latex presentations on this list some time ago (Russ
posted a fix to page to handle some mangled PostScript)...

I've done fine with presenting pdf or ps in a full-screen 'page' window on a
1024x768 laptop screen...

When talking about Plan 9 it is also useful to be able to hide the
presentation screen and show a few examples right there on the spot,
demo-style :)

I've sent Sam a sample presentation already, but didn't want to bother the
list with it. Another suggestion at the time was to use troff :)

andrey

On Sat, 15 Feb 2003, Scott Schwartz wrote:

> | I could use the extant doc prep
> | tools I'm becoming increasingly familiar
> | with.
>
> Not a Plan 9 specific answer, but...  I rather like latex with the
> prosper package.  Ideally it is used to make pdf, and can take advantage
> of acroread's features, but straight ps output should be usable.
>

Re: [9fans] presentation preparation

[Ralph Corderoy]

Hi andrey,

> Another suggestion at the time was to use troff :)

Bob Diertens' http://www.science.uva.nl/~bobd/useful/gpresent/ is useful
for producing PDF presentations using GNU troff.

Cheers,

--
Ralph Corderoy.      http://inputplus.co.uk/ralph/     http://troff.org/

[9fans] union directories

[Jack Johnson]

Ronald G. Minnich wrote:
 > truthfully, how many of you out there started out using disk/kfscmd
 > allow when you wanted to modify the kernel source?

I'll admit it, but I'm still a newbie so I have an extension of this
question.

Is there any way to, say, recompile a source tree with subfolders
without pre-creating those subfolders in the union directory?  Or,
what's the correct way to do something like:

mkdir 9
bind -bc 9 9
bind -ac /sys/src/9 9
cd 9
mk

(though that's not what I'm doing, I'm just needed an easy example)

-Jack

Re: [9fans] union directories

[Russ Cox]

there's no good way to do a recursive bind.
for the kernel you could piece it together with

t=/usr/you/9
bind -bc $t/pc /sys/src/9/pc
bind -bc $t/boot /sys/src/9/boot
cd /sys/src/9/pc
mk

Re: [9fans] union directories

[Adrian Tritschler]

Jack Johnson wrote:
> Ronald G. Minnich wrote:
>> truthfully, how many of you out there started out using disk/kfscmd
>> allow when you wanted to modify the kernel source?

I'll admit it.  How many knew any other way?  How many yet know?  Maybe a
little mention on the Wiki at
http://plan9.bell-labs.com/wiki/plan9/Compiling_kernels would be helpful.

Several months into my plan9 learning and I'm still getting my head around the
plan9 way of doing some things... most things...

> I'll admit it, but I'm still a newbie so I have an extension of this
> question.
> 
> Is there any way to, say, recompile a source tree with subfolders
> without pre-creating those subfolders in the union directory?  Or,
> what's the correct way to do something like:
> 
> mkdir 9
> bind -bc 9 9
> bind -ac /sys/src/9 9
> cd 9
> mk
> 
> (though that's not what I'm doing, I'm just needed an easy example)
> 
> -Jack

	Adrian

---------------------------------------------------------------
Adrian Tritschler    mailto:Adrian.Tritschler@its.monash.edu.au
Latitude 38°S, Longitude 145°E, Altitude 50m,      Shoe size 44
---------------------------------------------------------------

Re: [9fans] presentation preparation

[Richard Miller]

> I'm working on a presentation and am
> wondering what approach other 9'ers take
> to preparing slides.

I write slides in html [actually in a simpler syntax which is
translated to html by an awk script] and use charon to display
them.

-- Richard

Re: [9fans] presentation preparation

[Russ Cox]

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

Attached are some presentations I've done using
troff and page, along with tools that make them
easier.

You can play with the variables at the end of tmac.ppt
(or the definitions themselves) to add color to various
parts.

I tend to shy away from color usually, though.
The auth talk is black and white, while the oscpu
presentation adds grey.

Russ

[-- Attachment #2: doc.tar.gz --]
[-- Type: application/octet-stream, Size: 12370 bytes --]

Re: [9fans] presentation preparation

[Fco.J.Ballesteros]

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

An alternative is to use either the foils macro package or
a derivative. This is the one I use along with the respective mkfile
with view, print, ... targets

hth

[-- Attachment #2: slides.tgz --]
[-- Type: application/x-tar, Size: 7848 bytes --]

Re: [9fans] how to avoid a memset() optimization

[Russ Cox]

>   He doesn't need to know about volatile -- that's the whole point.
>   Once "experienced" programmer has set the buffer that way, the
>   less experienced just gets less chance to screw himself up

I'd still rather see it closer to the use that needs it.
If you're used to seeing secmemset then seeing
memset is a big red flag.  If you're used to seeing
memset with a volatile declaration, then you have
to seek out the volatile declaration, which might not
be anywhere near the call to memset.

This is a stupid argument anyway.  Volatile is a crock.
Here's another problem.  Suppose I'm worried that
leaking the processor flags at the end of my computation
might reveal something about the secret key.  I want to
clear them.  I could do something like:

	x = 0 & 0;

which in this particular case will clear the appropriate
flags.  But now the compiler comes along and optimizes
away the whole expression.  Where do I put my volatile
to make that stay?  Hmm?  The answer is not more crappy
qualifiers.  The answer is clearly dumber compilers.

Russ

Re: [9fans] how to avoid a memset() optimization

[Douglas A. Gwyn]

Russ Cox wrote:
> This is a stupid argument anyway.  Volatile is a crock.
> Here's another problem.  Suppose I'm worried that
> leaking the processor flags at the end of my computation
> might reveal something about the secret key.  I want to
> clear them.  I could do something like:
> 	x = 0 & 0;
> which in this particular case will clear the appropriate
> flags.  But now the compiler comes along and optimizes
> away the whole expression.  Where do I put my volatile
> to make that stay?  Hmm?  The answer is not more crappy
> qualifiers.  The answer is clearly dumber compilers.

Do you really want the compiler to always generate code
	MOV	R1,#0
	MOV	R2,#0
	AND	R2,R1
	MOV	R2,X(SP)
?  Almost any modern compiler will peform the AND at
compiler time (constant folding), and most customers want
that.  Anyway, I don't see why you need to AND in this
context.  Are you talking about the C and V bits?  If some
other process can inspect those for your process I'd think
it could inspect a whole lot more..

It is certainly true that we could really use better access
to the C bit from higher-level language source code.  This
shows up especially in the MP library.  But exploiting too
specific knowledge about the workings of a specific platform
can be dangerous, as we've seen historically.  If anybody
can devise a *nice* way to get at the C bit in MP coding,
please let me know so that it can be proposed for C0x.

Re: [9fans] how to avoid a memset() optimization

[Sam]

> Do you really want the compiler to always generate code
> 	MOV	R1,#0
> 	MOV	R2,#0
> 	AND	R2,R1
> 	MOV	R2,X(SP)

Yes, yes, and yes.  Optimizations which intelligently manage
register allocation are about as far as *I* appreciate.  Do
precisely what I say, and no less.  If I write poor code,
boo hoo for me.  Heavily optimizing compilers will *never*
make all coders equal and generally cause more headaches
than they're worth.

I do appreciate some warnings (ie if I forget to initialize
a variable to zero before I use it), but some of them are
just irritating.  Brantley looked over my shoulder a while
back and wondered why I was typing:

	if((m=fn())) {
		...
	}

saying, "what's with the extra parenthesis?"  "Oh, gcc complains
that I should surround assignment values used as a truth statement
and I've just incorporated it by habit to shut it up."

I hadn't even realized I was permitting gcc to define my style.
In essence, by permitting mad optimizations and then having to
do backflips just to keep the compiler from optimizing away
our real intentions, we're doing the same thing.  I hardly see
this as useful.

Cheers,

Sam

Re: [9fans] how to avoid a memset() optimization

[Scott Schwartz]

I, for one, like optimizing compilers.  Sure, sometimes you need fine-
grained control, but mostly I want faster code.  But like rob says, maybe
something other than C is what's called for.

Re: [9fans] how to avoid a memset() optimization

[Boyd Roberts]

I'd rather have slow and right over fast and broken.

Re: [9fans] how to avoid a memset() optimization

[plan9]

On Thu, Nov 14, 2002 at 04:26:08PM +0100, Boyd Roberts wrote:
> I'd rather have slow and right over fast and broken.

You and the other 5% of the world's consumers.

Re: [9fans] how to avoid a memset() optimization

[Sam]

Let's define "slow."  The last time I did a performance
test was on a des module I wrote.  The gcc compiled
-02 ran .2-.4 seconds faster (out of 3-4s).  Further
optlevels were not any better.

Anyone have any numbers showing that, "without optimizations,
this simply wouldn't be tolerable," in the face of well
written code?  In these instances does the compiler
generate crap code from the start, expecting an optimizer
to come clean it up later?

We wrote a C compiler for the language as of about
'73 for a coldfire target and it was a very telling
experience.  It was rather obvious that a simple
peephole optimizer would handle most of the inefficiencies
in the generated assy.  The code ran fast enough for
our purpose, however, so we didn't bother.  Indeed,
the human-time component is the most expensive
resource.  It's a shame 95% of the world doesn't
understand that.

Cheers,

Sam

On Thu, 14 Nov 2002 plan9@sigint.cs.purdue.edu wrote:

> On Thu, Nov 14, 2002 at 04:26:08PM +0100, Boyd Roberts wrote:
> > I'd rather have slow and right over fast and broken.
>
> You and the other 5% of the world's consumers.
>

Re: [9fans] how to avoid a memset() optimization

[Steve Kilbane]

> I'd rather have slow and right over fast and broken.

Others have different opinions. There are several issues here.

1. Some people want near-to-optimal code for the machine they've
chosen (slower code means faster machine needed, means higher price,
means fewer sales), and they want it soon (before their competitors
get all the market share). The economics of those markets mean they
need optimizing compilers. Vendors are happy to fill that need.

2. The language is being used for two different purposes: expressing
an abstract algorithm, and controlling the machine. These conflict.

3. There's a scary number of people out there who don't understand
the language they're using, and define it in terms of "Microsoft
gets it right," or "gcc does it properly", without realising they've
just been lucky. Their code can break from one compiler to another,
without having to optimize it. Optimizers just make it more obvious.

steve

Re: [9fans] how to avoid a memset() optimization

[Douglas A. Gwyn]

Steve's reponse was very nice.  Another way of putting it
is that the "right" behavior is not at all obvious once
you think hard enough about it and examine a wide enough
variety of platforms and application requirements.  One
of the tasks undertaken by the C standards committee was
to negotiate among the conflicting demands and to draw
the line somewhere.  Individuals would very likely draw
the line in other places, depending on their personal
prejudices and values.  If the existing standard
specification is causing significant real problems, there
is a mechanism in place to get it reconsidered and maybe
the official line could be redrawn.  The really important
thing is to understand where the official line *is* and
to observe it (on both sides, programmer and implementor);
that allows all parties to work together even if they all
still want to grumble about some aspect of the work..

Re: [9fans] how to avoid a memset() optimization

[Dan Cross]

I like Proebsting's law.  Compiler optimizations will get you a 2 fold
increase in speed once every 18 years.  That said, I wouldn't give up
the optimizations I have now, but I'm not married to them.

	- Dan C.

Re: [9fans] how to avoid a memset() optimization

[Douglas A. Gwyn]

Dan Cross wrote:
> I like Proebsting's law.  Compiler optimizations will get you a 2
> fold increase in speed once every 18 years.

Do you mean, that optimization technology improves at that rate?
For RISC architectures it is hard to tell optimization apart from
simply doing a good job of allocating registers, pipelines, etc.

Re: [9fans] how to avoid a memset() optimization

[Dan Cross]

> > I like Proebsting's law.  Compiler optimizations will get you a 2
> > fold increase in speed once every 18 years.
>
> Do you mean, that optimization technology improves at that rate?

Yes.  He states it much more succinctly than I did:
http://research.microsoft.com/~toddpro/papers/law.htm

> For RISC architectures it is hard to tell optimization apart from
> simply doing a good job of allocating registers, pipelines, etc.

That's true, but eliminating whole function calls is pretty clearly
an optimization.

	- Dan C.

Re: [9fans] how to avoid a memset() optimization

[Douglas A. Gwyn]

> > Do you really want the compiler to always generate code
> >       MOV     R1,#0
> >       MOV     R2,#0
> >       AND     R2,R1
> >       MOV     R2,X(SP)
Sam wrote:
> Yes, yes, and yes.  Optimizations which intelligently manage
> register allocation are about as far as *I* appreciate.  Do
> precisely what I say, and no less.

I intentionally mimicked the PDP-11 in my example since it supports
nearly a direct mapping from C to instructions.  However, on many
modern machines there is no such direct mapping for many of (old)
C constructs, so trying to control code generation through use of
C source code is fruitless.  And once you accept that principle,
it is hard to tell what constitutes optimization versus simple
code generation.  If you want assembly language you know where to
find it...

Re: [9fans] how to avoid a memset() optimization

[Roman V. Shaposhnick]

On Thu, Nov 14, 2002 at 01:53:04AM -0500, Russ Cox wrote:
> >   He doesn't need to know about volatile -- that's the whole point.
> >   Once "experienced" programmer has set the buffer that way, the
> >   less experienced just gets less chance to screw himself up
>
> to make that stay?  Hmm?  The answer is not more crappy
> qualifiers.  The answer is clearly dumber compilers.

  Or may be the answer is
     #pragma get your hands off my data, your psycho

  ;)

Thanks,
Roman.

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?

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

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

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?

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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
>

[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

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?

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

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

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

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

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

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

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

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

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

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

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

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

[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