World: r3wp

Well, thanks for reducing it.

Please note this in a ticket comment. It might be related to the 
sequence. In a fresh console on Windows, 6 will work every time.

6 works on Linux and OSX on a fresh console every time as well.

7 crashes both after the third call.

so its probably heap corruption.

Updated the description related to the number.

Certainly looks like a memory corruption issue from the outside, 
yes.

Will be much easier to pin down from the inside.

The heap corruption might be the cause of #1207 as well.

Sorry, I meant #1806.

Where exactly is one supposed to store user specific data for scripts 
eg. userid and passwords

for esmtp etc

We've talked about it before. It isn't defined yet

Is this something we can define then?  Reach a concensus?

Probably

Anyone with a suitable suggestion?

I'm suggesting a couple of wrapper functions to return userid and 
password etc so that these can be changed if the store system changes

That's a good principle

The only consensus we reached was that %user.r would be a good place 
to store preferences, and that it should only store data. Executable 
code would be prohibited in %user.r, and screened for. But we never 
started the discussion of how the preference data would be formatted 
or managed.

The no-executable-code thing is a security issue. R2's treatment 
of %rebol.r and %user.r is a big hole.

So, do we have a plan .. ??

Andreas is collecting blocks ..

These settings shouldn't go into system/user in R3, they should go 
in system/options/user. The system object will be task-specific, 
but the options are probably going to be global. And system/options/user 
might best be a map!, with categorized options in sub- maps, blocks 
or objects, depending on the situation. Or better yet just sub-maps, 
with the serialized preferences in blocks of name-value pairs so 
they can be parsed, and converted to maps at runtime.

system/options/user: make map! [
    category1 #[map! [
        option1 "value1"
        ...
    ]
    ...
]

Two-level category-options, and then the values could be any type 
you want. Screen thoroughly for evil values.

The %user.r serialization of this data should be human-writeable 
and loaded with LOAD, not DO.

The advantage to serializing directly in SAVE/all form is speed. 
The disadvantages are:

- The preferences file would be uglier to write by hand than block 
form.

- You would have to screen with ASSERT/type in FOREACH instead of 
PARSE.

But the slowness of validating would be offset by the speed of loading 
and saving, so it might be worth it.

Another disadvantage is that loading errors are currently harder 
to recover from with serialized constructors than they are with normal 
literal values like blocks. There's a ticket about this already. 
However, if you are loading the entire preference file in one go 
and just catching the error with TRY, there's no difference in the 
error handling.

The only consensus we reached was that %user.r would be a good place 
to store preferences, and that it should only store data. Executable 
code would be prohibited in %user.r, and screened for.
 - frankly, that decision never made sense to me.

In my opinion, it is not more secure at all.

...and I am afraid, that it is not hard to prove

...serialized constructors...
 - For me, the terminology is quite unfortunate, because

     "1 2"

is not "more serialized" than

    "#[false] #[true]"


I still do not understand, why it is so important to pretend the 
opposite.

Such an approach just leads to bugs.

Instead of saying 'not "more serialized"', I should have said 'not 
"more or less serialized"'

Interesting point.  I would suspect the goal is to have the first, 
or top level be "code free", such that it is just settings.

But then, if you "want" you can call upon other files that contain 
code.

As a concept it sounds smart, which is unrelated to the reality that 
it might not be possible.

So, "is it" possible.

Serialized constructors as opposed to serialized values. I used the 
"constructors" term to emhpasize the difference because the important 
distinction in that statement is the additional code that those constructions 
run in the loading process, beyond that in TRANSCODE itself. See 
http://issue.cc/r3/1857for the bug in question.

The security issue is to not have a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under. It's a way to prevent worms.

The real distinction is between serialized constructors: #[map! [a 
1]]

and programmatic constructors that you have to DO: make map! [a 1]

The security issue is to not have a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under.

- I do not have any problem to agree with that. But, in my opinion, 
this does not require to ban files, that are done automatically. 
Rather, we should make it possible to define special rights for such 
files.

real distinction is between serialized constructors: #[map! [a 1]]...

 - in my opinion, these are not "constructors" for REBOL programmers, 
 since they cannot define them

Not at the OS level. We can only define permissions within REBOL 
itself, not permissions when it isn't running. And REBOL doesn't 
have any facility for user-specific permissions.

Ladislav, REBOL programmers can't define constructors, but they are 
still constructors. We can't define MAKE behavior either (until we 
get user-defined types).

as said, for me the formulation: "...a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under..." is substantial, and it can be done, as far as I know.

Technically, the #[map! []] syntax is not a constructor itself, it 
merely calls a constructor :)

The security issue is to not have a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under.

sorry, i don't get that. could you try reformulate the problem?

REBOL programmers can't define constructors, but they are still constructors
 - technically not, since they are not definable

The definability is a property that is used to explain what a constructor 
is.

Being defineable doesn't make it a constructor. Constructing something 
does.

OK, my opinion:


The user does neither "see" nor is able to define any constructors. 
What you are referring to are some syntactic constructs, that are 
not constructors at all.