dsimcha, el 6 de noviembre a las 02:13 me escribiste:
> == Quote from Leandro Lucarella (llu...@gmail.com)'s article
> > Andrei Alexandrescu, el 5 de noviembre a las 09:57 me escribiste:
> > > Leandro Lucarella wrote:
> > > >Andrei Alexandrescu, el 5 de noviembre a las 08:48 me escribiste:
> > >
== Quote from Leandro Lucarella (llu...@gmail.com)'s article
> Andrei Alexandrescu, el 5 de noviembre a las 09:57 me escribiste:
> > Leandro Lucarella wrote:
> > >Andrei Alexandrescu, el 5 de noviembre a las 08:48 me escribiste:
> > >>First off: _all_ languages except C, C++, and assembler are or
Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> You're forgetting about all other system programming languages.
Delphi.
>> Also,
>> many of these claims to safety are demonstrably false.
>
> Which?
I can get Python to segfault.
> Memory safety is defined formally in Pierce's book.
Do you
Andrei Alexandrescu, el 5 de noviembre a las 09:57 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 5 de noviembre a las 08:48 me escribiste:
> >>First off: _all_ languages except C, C++, and assembler are or at
> >>least claim to be safe. All. I mean ALL. Did I mention all? I
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
First off: _all_ languages except C, C++, and assembler are or at least
claim to be safe. All. I mean ALL. Did I mention all? If that was some
ideology that is not realistic, is extremely difficult to achieve, and
ends up too painful to use, then su
Andrei Alexandrescu wrote:
> First off: _all_ languages except C, C++, and assembler are or at least
> claim to be safe. All. I mean ALL. Did I mention all? If that was some
> ideology that is not realistic, is extremely difficult to achieve, and
> ends up too painful to use, then such theories wou
Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> '-safe' turns on runtime safety checks, which can be and should be
>> mostly orthogonal to the module safety level.
>
> Runtime vs. compile-time is immaterial.
The price of compile-time checks is that you are restricted to a subset
of the langua
Michal Minich wrote:
[snip]
Therefore I propose to use F safety.
[snip]
I think you've made an excellent case.
Andrei
On Wed, 04 Nov 2009 14:24:47 -0600, Andrei Alexandrescu wrote:
>> But efficiency is also important, and if you want it, why not move the
>> code subjected to bounds checks to trusted/system module - I hope they
>> are not checked for bounds in release mode. Moving parts of the code to
>> trusted m
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
module name; // interface: unsafe impl.: unsafe
module (system) name; // interface: safe impl.: unsafe
module (safe) name; // interface: safe impl.: safe
so you can call system modules (io, network...) f
Andrei Alexandrescu wrote:
>> module name; // interface: unsafe impl.: unsafe
>> module (system) name; // interface: safe impl.: unsafe
>> module (safe) name; // interface: safe impl.: safe
>>
>> so you can call system modules (io, network...) from safe
Michal Minich wrote:
On Wed, 04 Nov 2009 13:12:54 -0600, Andrei Alexandrescu wrote:
But I think there is no reason no use -no-safe compiler flag ... for
what reason one would want to force safer program to compile as less
safer :)
Efficiency (e.g. remove array bounds checks).
As I'm thinking
On Wed, 04 Nov 2009 13:12:54 -0600, Andrei Alexandrescu wrote:
>> But I think there is no reason no use -no-safe compiler flag ... for
>> what reason one would want to force safer program to compile as less
>> safer :)
>
> Efficiency (e.g. remove array bounds checks).
>
>> As I'm thinking more a
Michal Minich, el 4 de noviembre a las 18:58 me escribiste:
> As I'm thinking more about it, I don't see any reason to have any
> compiler flag for safety at all.
That was exacly my point.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
---
Michal Minich wrote:
On Wed, 04 Nov 2009 14:03:42 -0300, Leandro Lucarella wrote:
I think safe should be the default, as it should be the most used flavor
in user code, right? What about:
module s; // interface: safe impl.: safe
module (trusted) t; // interface: safe imp
On Wed, 04 Nov 2009 14:03:42 -0300, Leandro Lucarella wrote:
> I think safe should be the default, as it should be the most used flavor
> in user code, right? What about:
>
> module s; // interface: safe impl.: safe
> module (trusted) t; // interface: safe impl.: unsafe
> m
Andrei Alexandrescu wrote:
> jpf wrote:
>> You may want to have a look at the CoreCLR security model (that's used
>> by silverlight / moonlight). It's quite similar to what you've proposed.
>> http://www.mono-project.com/Moonlight2CoreCLR#Security_levels
>
> I don't have much time right now, but h
Jesse Phillips wrote:
Andrei Alexandrescu Wrote:
Jesse Phillips wrote:
On Tue, 03 Nov 2009 23:13:14 -0600, Andrei Alexandrescu wrote:
I think the only real option is to have the importer decide if it is
trusted.
That can't work. I can't say that stdc.stdlib is trusted no matter how
hard I t
Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
module(safe) is not a comment. We need three types of modules
because of the interaction between what the module declares and what
the command line wants.
Let's assume the d
jpf wrote:
Andrei Alexandrescu wrote:
How can we address that? Again, I'm looking for a simple, robust,
extensible design that doesn't lock our options.
Thanks,
Andrei
You may want to have a look at the CoreCLR security model (that's used
by silverlight / moonlight). It's quite similar to wh
Andrei Alexandrescu, el 4 de noviembre a las 08:16 me escribiste:
> Michal Minich wrote:
> >Hello Michel,
> >
> >>module (system) name; // interface: unsafe impl.: unsafe
> >>module (safe) name; // interface: safe impl.: safe
> >
> >I thought that first (unsafe-unsafe) case
Andrei Alexandrescu Wrote:
> Jesse Phillips wrote:
> > On Tue, 03 Nov 2009 23:13:14 -0600, Andrei Alexandrescu wrote:
> >
> >>> I think the only real option is to have the importer decide if it is
> >>> trusted.
> >> That can't work. I can't say that stdc.stdlib is trusted no matter how
> >> hard
Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
module(safe) is not a comment. We need three types of modules because
of the interaction between what the module declares and what the
command line wants.
Let's assume the default, no-f
Andrei Alexandrescu wrote:
> How can we address that? Again, I'm looking for a simple, robust,
> extensible design that doesn't lock our options.
>
>
> Thanks,
>
> Andrei
You may want to have a look at the CoreCLR security model (that's used
by silverlight / moonlight). It's quite similar to wha
Leandro Lucarella wrote:
Walter Bright, el 3 de noviembre a las 16:21 me escribiste:
Andrei Alexandrescu wrote:
Sketch of the safe rules:
\begin{itemize*}
\item No @cast@ from a pointer type to an integral type and vice versa
replace integral type with non-pointer type.
\item No @cast@ bet
Leandro Lucarella wrote:
Andrei Alexandrescu, el 3 de noviembre a las 17:54 me escribiste:
Leandro Lucarella wrote:
Andrei Alexandrescu, el 3 de noviembre a las 16:33 me escribiste:
SafeD is, unfortunately, not finished at the moment. I want to leave
in place a stub that won't lock our optio
Walter Bright, el 3 de noviembre a las 16:21 me escribiste:
> Andrei Alexandrescu wrote:
> >Sketch of the safe rules:
> >
> >\begin{itemize*}
> >\item No @cast@ from a pointer type to an integral type and vice versa
>
> replace integral type with non-pointer type.
>
> >\item No @cast@ between un
Michel Fortin Wrote:
> How is this supposed to work correctly with and without the "-safe"
> compiler flag? The way you define things "-safe" would make module
> memory safe for use while it is not.
"-safe" would cause the compiler to check if the code was safe and error out if
it wasn't. Not
Andrei Alexandrescu, el 3 de noviembre a las 17:54 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 3 de noviembre a las 16:33 me escribiste:
> >>SafeD is, unfortunately, not finished at the moment. I want to leave
> >>in place a stub that won't lock our options. Here's what w
Hello Don,
Michal Minich wrote:
Hello Michel,
I'm not sure this works so well. Look at this:
module memory; // unsafe interface - unsafe impl.
extern (C) void* malloc(int);
extern (C) void free(void*);
module (system) my.system; // safe interface - unsafe impl.
import memory;
void test(
Jesse Phillips wrote:
On Tue, 03 Nov 2009 23:13:14 -0600, Andrei Alexandrescu wrote:
I think the only real option is to have the importer decide if it is
trusted.
That can't work. I can't say that stdc.stdlib is trusted no matter how
hard I try. I mean free is there!
I would like to disagree
On Tue, 03 Nov 2009 23:13:14 -0600, Andrei Alexandrescu wrote:
>> I think the only real option is to have the importer decide if it is
>> trusted.
>
> That can't work. I can't say that stdc.stdlib is trusted no matter how
> hard I try. I mean free is there!
I would like to disagree here.
void f
Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
module(safe) is not a comment. We need three types of modules because
of the interaction between what the module declares and what the
command line wants.
Let's assume the default, no-flag build allows unsafe code
Walter Bright wrote:
Andrei Alexandrescu wrote:
Sketch of the safe rules:
\begin{itemize*}
\item No @cast@ from a pointer type to an integral type and vice versa
replace integral type with non-pointer type.
\item No @cast@ between unrelated pointer types
\item Bounds checks on all array acc
Michal Minich wrote:
Hello Michel,
I'm not sure this works so well. Look at this:
module memory; // unsafe interface - unsafe impl.
extern (C) void* malloc(int);
extern (C) void free(void*);
module (system) my.system; // safe interface - unsafe impl.
import memory;
void test() { auto i = m
Hello Michel,
I'm not sure this works so well. Look at this:
module memory; // unsafe interface - unsafe impl.
extern (C) void* malloc(int);
extern (C) void free(void*);
module (system) my.system; // safe interface - unsafe impl.
import memory;
void test() { auto i = malloc(10); free(i); }
Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
module(safe) is not a comment. We need three types of modules because of
the interaction between what the module declares and what the command
line wants.
Let's assume the default, no-flag build allows unsafe code, like right
On 2009-11-04 09:29:21 -0500, Michal Minich said:
Hello Andrei,
Michal Minich wrote:
Hello Michel,
module (system) name; // interface: unsafe impl.: unsafe
module (safe) name; // interface: safe impl.: safe
I thought that first (unsafe-unsafe) case is currently a
Hello Andrei,
Michal Minich wrote:
Hello Michel,
module (system) name; // interface: unsafe impl.: unsafe
module (safe) name; // interface: safe impl.: safe
I thought that first (unsafe-unsafe) case is currently available just
by:
module name; // interface: unsafe
Michal Minich wrote:
Hello Michel,
module (system) name; // interface: unsafe impl.: unsafe
module (safe) name; // interface: safe impl.: safe
I thought that first (unsafe-unsafe) case is currently available just by:
module name; // interface: unsafe impl.: unsafe
Don wrote:
Andrei Alexandrescu wrote:
SafeD is, unfortunately, not finished at the moment. I want to leave
in place a stub that won't lock our options. Here's what we currently
have:
module(system) calvin;
This means calvin can do unsafe things.
module(safe) susie;
This means susie commits
Hello Michel,
module (system) name; // interface: unsafe impl.: unsafe
module (safe) name; // interface: safe impl.: safe
I thought that first (unsafe-unsafe) case is currently available just by:
module name; // interface: unsafe impl.: unsafe
separating modules to
Aelxx Wrote:
>
> "Andrei Alexandrescu" ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ ×
> ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ: news:hcr2hb$dv...@digitalmars.com...
> > Jesse Phillips wrote:
> >> On Tue, 03 Nov 2009 17:55:15 -0600, Andrei Alexandrescu wrote:
> >>
> >>> There's a lot more, but there are a few useful subspaces. One is, if an
>
Andrei Alexandrescu Wrote:
> Jason House wrote:
> > Walter Bright Wrote:
> >
> >> Andrei Alexandrescu wrote:
> >>> Sketch of the safe rules:
> >>>
> >>> \begin{itemize*} \item No @cast@ from a pointer type to an
> >>> integral type and vice versa
> >> replace integral type with non-pointer type.
On 2009-11-03 17:33:39 -0500, Andrei Alexandrescu
said:
So these are my thoughts so far. There is one problem though related to
the last \item - there's no way for a module to specify "trusted",
meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me
no problem". Many modules
Andrei Alexandrescu wrote:
SafeD is, unfortunately, not finished at the moment. I want to leave in
place a stub that won't lock our options. Here's what we currently have:
module(system) calvin;
This means calvin can do unsafe things.
module(safe) susie;
This means susie commits to extra che
"Andrei Alexandrescu" ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ ×
ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ: news:hcr2hb$dv...@digitalmars.com...
> Jesse Phillips wrote:
>> On Tue, 03 Nov 2009 17:55:15 -0600, Andrei Alexandrescu wrote:
>>
>>> There's a lot more, but there are a few useful subspaces. One is, if an
>>> entire application only u
On Tue, 03 Nov 2009 17:33:39 -0500, Andrei Alexandrescu
wrote:
SafeD is, unfortunately, not finished at the moment. I want to leave in
place a stub that won't lock our options. Here's what we currently have:
module(system) calvin;
This means calvin can do unsafe things.
module(safe) susi
Jason House wrote:
Walter Bright Wrote:
Andrei Alexandrescu wrote:
Sketch of the safe rules:
\begin{itemize*} \item No @cast@ from a pointer type to an
integral type and vice versa
replace integral type with non-pointer type.
\item No @cast@ between unrelated pointer types \item Bounds
che
Jason House wrote:
How does casting away const, immutable, or shared cause memory
corruption? If I understand SafeD correctly, that's its only goal. If
it does more, I'd also argue casting to shared or immutable is, in
general, unsafe.
They can cause memory corruption because inadvertent "teari
Jesse Phillips wrote:
On Tue, 03 Nov 2009 17:55:15 -0600, Andrei Alexandrescu wrote:
There's a lot more, but there are a few useful subspaces. One is, if an
entire application only uses module(safe) that means there is no memory
error in that application, ever.
Andrei
Does that mean that a m
Walter Bright Wrote:
> Andrei Alexandrescu wrote:
> > Sketch of the safe rules:
> >
> > \begin{itemize*}
> > \item No @cast@ from a pointer type to an integral type and vice versa
>
> replace integral type with non-pointer type.
>
> > \item No @cast@ between unrelated pointer types
> > \item Bo
On Tue, 03 Nov 2009 17:55:15 -0600, Andrei Alexandrescu wrote:
> There's a lot more, but there are a few useful subspaces. One is, if an
> entire application only uses module(safe) that means there is no memory
> error in that application, ever.
>
> Andrei
Does that mean that a module that uses
Bill Baxter wrote:
On Tue, Nov 3, 2009 at 2:33 PM, Andrei Alexandrescu
wrote:
SafeD is, unfortunately, not finished at the moment. I want to leave in
place a stub that won't lock our options. Here's what we currently have:
module(system) calvin;
This means calvin can do unsafe things.
module
Leandro Lucarella wrote:
Andrei Alexandrescu, el 3 de noviembre a las 16:33 me escribiste:
SafeD is, unfortunately, not finished at the moment. I want to leave
in place a stub that won't lock our options. Here's what we
currently have:
module(system) calvin;
This means calvin can do unsafe th
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> SafeD is, unfortunately, not finished at the moment. I want to leave in
> place a stub that won't lock our options. Here's what we currently have:
> module(system) calvin;
> This means calvin can do unsafe things.
> modul
"Andrei Alexandrescu" wrote in message
news:hcqb44$1nc...@digitalmars.com...
> SafeD is, unfortunately, not finished at the moment. I want to leave in
> place a stub that won't lock our options. Here's what we currently have:
>
> module(system) calvin;
>
> This means calvin can do unsafe things.
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
SafeD is, unfortunately, not finished at the moment. I want to leave in
place a stub that won't lock our options. Here's what we currently have:
module(system) calvin;
This means calvin can do unsafe thing
Nick Sabalausky wrote:
module(system, trusted) calvin;
?
Yah, I was thinking of something along those lines. What I don't like is
that trust is taken, not granted. But then a model with granted trust
would be more difficult to define.
Andrei
On Tue, Nov 3, 2009 at 3:54 PM, Andrei Alexandrescu
wrote:
> Leandro Lucarella wrote:
>>
>> Andrei Alexandrescu, el 3 de noviembre a las 16:33 me escribiste:
>>>
>>> SafeD is, unfortunately, not finished at the moment. I want to leave
>>> in place a stub that won't lock our options. Here's what w
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:hcqc3m$1pg...@digitalmars.com...
Nick Sabalausky wrote:
module(system, trusted) calvin;
?
Yah, I was thinking of something along those lines. What I don't like is
that trust is taken, not granted. But then a model with granted
On Tue, Nov 3, 2009 at 2:33 PM, Andrei Alexandrescu
wrote:
> SafeD is, unfortunately, not finished at the moment. I want to leave in
> place a stub that won't lock our options. Here's what we currently have:
>
> module(system) calvin;
>
> This means calvin can do unsafe things.
>
> module(safe) su
SafeD is, unfortunately, not finished at the moment. I want to leave in
place a stub that won't lock our options. Here's what we currently have:
module(system) calvin;
This means calvin can do unsafe things.
module(safe) susie;
This means susie commits to extra checks and therefore only a sub
"Andrei Alexandrescu" wrote in message
news:hcqc3m$1pg...@digitalmars.com...
> Nick Sabalausky wrote:
>> module(system, trusted) calvin;
>> ?
>
> Yah, I was thinking of something along those lines. What I don't like is
> that trust is taken, not granted. But then a model with granted trust
> wo
Andrei Alexandrescu, el 3 de noviembre a las 16:33 me escribiste:
> SafeD is, unfortunately, not finished at the moment. I want to leave
> in place a stub that won't lock our options. Here's what we
> currently have:
>
> module(system) calvin;
>
> This means calvin can do unsafe things.
>
> mod
Andrei Alexandrescu wrote:
Sketch of the safe rules:
\begin{itemize*}
\item No @cast@ from a pointer type to an integral type and vice versa
replace integral type with non-pointer type.
\item No @cast@ between unrelated pointer types
\item Bounds checks on all array accesses
\item No union
66 matches
Mail list logo
