World: r3wp

Geomol, you can use any other refinement, why use /local and allow 
a huge gap in security wrt intent of a local varable.  

I'd actually replace the /local handling of the function dialect 
and allow you to specify default values right in the function block.

f: func [a b /local i: 2 blk: [ ] ] [...]


The idea of /local is that its a protected, internal, set of words... 
most people don't even realize that it is just another normal refinement.

but the idea is that we usually limit the input types when it matters. 
 and the function has to do the handling of the /local refinement.


I'd much rather get an interpreter error telling me I can't use or 
apply /local refinements.  this would also mean that /local would 
have to be the last refinement... always.

Maybe we should see some examples to better judge this.

How are arguments used? You can set them using set-word! or just 
use the word. If you just use an argument, your "inject code" could 
be a problem, not if you use it as a set-word!. But normal arguments 
you just use, so your problem is there already, or what?

Take REPLACE as an example of a function with locals. See how locals 
are used by looking at the source. I don't think, the thing about 
/local is an existing problem.

All I'm saying, John, is that currently we have to manually "close 
the doors", there are no ways within the language to make words private 
from the outside without doing the work ourself.


and most people don't realize that there is no such thing as a local 
word in rebol functions.  we only have arguments, which looks like 
a weird missing feature.

I'm a bit in doubt, because as you say, people might see this as 
a missing feature, even if it's not a problem. But wouldn't it be 
able to produce a function creator like FUNC, that makes a context 
with the locals, and then the function itself within the context 
and with the rest of the arguments?

wouldn't *we* ...

yep, we can build our own function builders but again, this means 
we do it ourself.  ;-)  


would just be nice if one refinement where reserved for inaccessible 
words.... which is what /local has been used for for 15 years (even 
though its been an illusion ;-)

Can you give an example of a function, where it's a problem, locals 
are not really local?

Maybe a function, where the local var is set, if some condition is 
fulfilled, and then the local is returned in the end, being NONE, 
if it wan't set. Is that an example of such a problem function?

*wasn't*

Here is an example of a function hi-jacking.


it is something that can commonly be seen in larger apps, where some 
locals are only used conditionally.  in this case, the original function 
is hijacked and we could really do nasty things here.


--------------------------------------------------------------------
rebol []

f: func [a [string! block!] /local str][

	; uncomment to make the function safe
	; str: none

	if block? a [
		str: mold a
	]
	print any [str a]
]

evil-func: func [a ][
	; do something evil here
	print "EVIL!" 
	head insert a " >:-P >>>  "
]

f/local "Print occurs as if nothing is wrong" :evil-func

ask "!"

Good example! :)
Houston, we have a problem!

using this trick we can get internal function values even if we cannot 
change function bodies anymore.


my point is not that this can be done with any arguments.  its just 
that the way we all use /locals, we don't include argument protection.

so I think its just a good thing to allow this functionality by default 
in the language, since we all use /locals as if it where already 
there.

What about the full FUNCTION form?

IIRC, its just a stub which creates a 'FUNC spec.

I remember it the other way around

on make function! ,  the argument spec is just one block, not two.

unless it's changed while I wasn't looking  ;-)(

Hm, yes, that makes the issue extra deceptive. FUNCTION looks like 
it has real locals

FUNCTION was the other way around, Kaj, but *long* ago

R1

Maxim, in your example, the user has access to the function f, can 
call it direcly. Let's say, we couldn't give the /local refinement, 
then I could just write:

	f evil-func "Print occurs as if nothing is wrong"


Why is it a problem, we can give the /local refinement? Isn't it 
false security, if it is changed, so we can't call with /local ?

Ah, a scheme engine leftover :-)

Carl reacted to its complexity with extreme simplicity, so this one 
may have been one bridge too far

i wish we would live in a world where u shouldn't be concerned about 
this kind of security issues :D

this concept is sooo lovely, that u can even build such a fundamental 
feature as local variable via the already existing specs dialect, 
my heart hurts to see we can't keep this virgin beauty and have to 
sacrifice it on the altar of security...

Yeah, I also thought it elegant when I heard about it, but on the 
other hand it violates the principle of least surprise

REBOL is too weird compared to other programming languages for it 
to really be possible or even desirable to avoid surprise :)

I know, but this one would be surprising in any language

Not any language - I think you are underestimating the variety in 
languages. Some don't have local variables at all, for instance.

Doesn't matter. The surprise is about local variables being initialisable 
from the outside

Local variables are by definition about encapsulation, and this is 
not encapsulation

The surprise being that there aren't really any local variables, 
just arguments which might be optional. There was a proposal to make 
there be non-argument local variables in R3, and I wouldn't be opposed 
to this, but "least surprise" isn't a good enough argument for why 
in such an inherently surprising language as REBOL. I also wouldn't 
be opposed to having FUNCT add an ASSERT/type [local none!] to the 
beginning of the code block of every function it generates.

That last trick would be difficult to do safely though, at least 
as FUNCT is used in the mezzanine generation process. Mezzanines 
are generated with FUNCT but saved with MOLD into the form where 
they will be loaded at runtime. This means that FUNCT can't generate 
code that has inline function or datatype values in it, since they 
won't mold properly. Unless you inline the references to ASSERT and 
NONE!, those words couldn't be used as function parameters or local 
variables in the generated functions. Tradeoffs, I guess.

I hereby propose to rename the /local refinement to /not-local

:-D

I can't figure out, if the /local behaviour is a real problem, or 
just one in our minds.

It has become a problem, now that people know it can be abused :-)

But who can abuse it? Just ourselves or outside hackers in a web 
application?

If it's just the programmer, who has full control over the functions 
anyway, then I see no problem.

Yeah, that's the criterium. You still need to be able to inject code

However, if someone gets a sandbox, every function made available 
can now be probed for code injection through this hole

For better local variables, you can use USE. But it's a bit clunky.

   f: func [a b][use [c] [c: a + b c]]   ;; 'c is local to the function, 
   and not easily/obviously affected by anything outside

It's really not any more of a problem for /local than it is for any 
other function option or argument, since the real problem is that 
the techniques for code injection have been revealed. Fortunately, 
so have the methods for avoiding or counteracting it: APPLY, type 
checking, get-words, or wrapping expressions in parens or putting 
them at the end of blocks to make sure that they can't get access 
to modifiable values later on in the block.

Sunanda, agreed, and also about it being clunky, particularly because 
USE has both COPY/deep and BIND/copy overhead in R3. ASSERT/type 
[local none!] is still the most efficient method.

Has anyone tried to use extensions in R3 OSX? Do these work?

Yes, they work. (Only did some basic testing, though.)

Callback as well then?