9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] useful language extension, or no?
@ 2002-07-18 15:02 forsyth
  2002-07-18 23:57 ` arisawa
  0 siblings, 1 reply; 52+ messages in thread
From: forsyth @ 2002-07-18 15:02 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-20  5:59 forsyth
  0 siblings, 0 replies; 52+ messages in thread
From: forsyth @ 2002-07-20  5:59 UTC (permalink / raw)
  To: 9fans

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.



^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-19 18:35 forsyth
  0 siblings, 0 replies; 52+ messages in thread
From: forsyth @ 2002-07-19 18:35 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-19 18:33 David Gordon Hogan
  0 siblings, 0 replies; 52+ messages in thread
From: David Gordon Hogan @ 2002-07-19 18:33 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-19 18:22 David Gordon Hogan
  2002-07-19 18:36 ` Digby Tarvin
  0 siblings, 1 reply; 52+ messages in thread
From: David Gordon Hogan @ 2002-07-19 18:22 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-19 15:45 forsyth
  2002-07-19 18:19 ` Digby Tarvin
  0 siblings, 1 reply; 52+ messages in thread
From: forsyth @ 2002-07-19 15:45 UTC (permalink / raw)
  To: 9fans

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.



^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-19  6:48 forsyth
  0 siblings, 0 replies; 52+ messages in thread
From: forsyth @ 2002-07-19  6:48 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-19  0:52 David Gordon Hogan
  2002-07-19 12:53 ` Digby Tarvin
  0 siblings, 1 reply; 52+ messages in thread
From: David Gordon Hogan @ 2002-07-19  0:52 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-18 19:24 David Gordon Hogan
  2002-07-19  4:22 ` Lucio De Re
  0 siblings, 1 reply; 52+ messages in thread
From: David Gordon Hogan @ 2002-07-18 19:24 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-18 12:54 Richard Miller
  0 siblings, 0 replies; 52+ messages in thread
From: Richard Miller @ 2002-07-18 12:54 UTC (permalink / raw)
  To: 9fans

> 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



^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-17 13:36 rob pike, esq.
  0 siblings, 0 replies; 52+ messages in thread
From: rob pike, esq. @ 2002-07-17 13:36 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-16 17:31 presotto
  2002-07-17  8:58 ` William Josephson
  2002-07-17  8:58 ` Douglas A. Gwyn
  0 siblings, 2 replies; 52+ messages in thread
From: presotto @ 2002-07-16 17:31 UTC (permalink / raw)
  To: 9fans

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


^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-16 17:01 forsyth
  2002-07-17  8:59 ` Douglas A. Gwyn
  0 siblings, 1 reply; 52+ messages in thread
From: forsyth @ 2002-07-16 17:01 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-16 16:50 rob pike, esq.
  2002-07-16 15:59 ` Sam
  0 siblings, 1 reply; 52+ messages in thread
From: rob pike, esq. @ 2002-07-16 16:50 UTC (permalink / raw)
  To: 9fans

> 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



^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-16 16:08 rob pike, esq.
  2002-07-16 15:31 ` Sam
  0 siblings, 1 reply; 52+ messages in thread
From: rob pike, esq. @ 2002-07-16 16:08 UTC (permalink / raw)
  To: 9fans

> 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



^ permalink raw reply	[flat|nested] 52+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-16 15:53 rob pike, esq.
  2002-07-16 15:05 ` Sam
  0 siblings, 1 reply; 52+ messages in thread
From: rob pike, esq. @ 2002-07-16 15:53 UTC (permalink / raw)
  To: 9fans

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

-rob



^ permalink raw reply	[flat|nested] 52+ messages in thread
* [9fans] useful language extension, or no?
@ 2002-07-16 14:12 Sam
  2002-07-16 16:30 ` Boyd Roberts
  2002-07-17 12:49 ` Ian Broster
  0 siblings, 2 replies; 52+ messages in thread
From: Sam @ 2002-07-16 14:12 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 52+ messages in thread

end of thread, other threads:[~2002-07-29 16:01 UTC | newest]

Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-18 15:02 [9fans] useful language extension, or no? forsyth
2002-07-18 23:57 ` arisawa
2002-07-29 15:59   ` Douglas A. Gwyn
  -- strict thread matches above, loose matches on Subject: below --
2002-07-20  5:59 forsyth
2002-07-19 18:35 forsyth
2002-07-19 18:33 David Gordon Hogan
2002-07-19 18:22 David Gordon Hogan
2002-07-19 18:36 ` Digby Tarvin
2002-07-19 15:45 forsyth
2002-07-19 18:19 ` Digby Tarvin
2002-07-19  6:48 forsyth
2002-07-19  0:52 David Gordon Hogan
2002-07-19 12:53 ` Digby Tarvin
2002-07-19 15:41   ` Mike Haertel
2002-07-19 18:09     ` Digby Tarvin
2002-07-19 18:38       ` Scott Schwartz
2002-07-19 19:07         ` Digby Tarvin
2002-07-29 16:01     ` Ralph Corderoy
2002-07-18 19:24 David Gordon Hogan
2002-07-19  4:22 ` Lucio De Re
2002-07-18 12:54 Richard Miller
2002-07-17 13:36 rob pike, esq.
2002-07-16 17:31 presotto
2002-07-17  8:58 ` William Josephson
2002-07-17  8:58 ` Douglas A. Gwyn
2002-07-16 17:01 forsyth
2002-07-17  8:59 ` Douglas A. Gwyn
2002-07-16 16:50 rob pike, esq.
2002-07-16 15:59 ` Sam
2002-07-16 17:04   ` Howard Trickey
2002-07-16 16:20     ` Sam
2002-07-16 16:08 rob pike, esq.
2002-07-16 15:31 ` Sam
2002-07-16 15:53 rob pike, esq.
2002-07-16 15:05 ` Sam
2002-07-16 21:29   ` Steve Kilbane
2002-07-16 14:12 Sam
2002-07-16 16:30 ` Boyd Roberts
2002-07-17 12:49 ` Ian Broster
2002-07-17 12:12   ` Sam
2002-07-17 13:33     ` Lucio De Re
2002-07-17 16:12       ` Fariborz (Skip) Tavakkolian
2002-07-17 22:21         ` arisawa
2002-07-17 22:28           ` Ronald G Minnich
2002-07-18  9:51           ` Douglas A. Gwyn
2002-07-18 10:19             ` Lucio De Re
2002-07-18 10:28               ` Lucio De Re
2002-07-18 14:50                 ` Mike Haertel
2002-07-18 14:56                   ` Lucio De Re
2002-07-19  5:23                   ` arisawa
2002-07-18 14:21               ` Douglas A. Gwyn
2002-07-18 14:55                 ` Lucio De Re

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).