On Monday, June 03, 2013 12:03:51 Steven Schveighoffer wrote:
> Think of @safe functions as bricks. By themselves, they are solid and
> will hold up a building well. But if you put them on top of garbage, they
> will be as useless as cardboard.
Nice analogy.
- Jonathan M Davis
On Sun, 02 Jun 2013 03:59:08 -0400, monarch_dodra
wrote:
On Saturday, 1 June 2013 at 22:15:00 UTC, Jonathan M Davis wrote:
Well, given that the safety of the operation relies on what's being
passed in,
the operation itself can't reasonably be marked as @safe, because you
can't
guarante
On Sunday, June 02, 2013 09:59:08 monarch_dodra wrote:
> On Saturday, 1 June 2013 at 22:15:00 UTC, Jonathan M Davis wrote:
> > On Saturday, June 01, 2013 23:41:32 monarch_dodra wrote:
> >> Now, it was *my* fault for calling emplace with an already
> >> built
> >> object, but it was the (@trusted) e
On Saturday, 1 June 2013 at 22:15:00 UTC, Jonathan M Davis wrote:
On Saturday, June 01, 2013 23:41:32 monarch_dodra wrote:
OK. But by that standard, can't (mostly) anything be trusted?
What about something that writes garbage, to a memory location
it
was *asked* to write to? Or if wrong usage
On Sunday, June 02, 2013 01:12:53 Piotr Szturmaj wrote:
> W dniu 01.06.2013 23:55, Jonathan M Davis pisze:
> > The guarantees of @safe hold only so long as there are no holes in it, but
> > any and all holes we find get fixed. Making ref be truly @safe has been a
> > large part of the recent ref di
W dniu 01.06.2013 23:55, Jonathan M Davis pisze:
The guarantees of @safe hold only so long as there are no holes in it, but any
and all holes we find get fixed. Making ref be truly @safe has been a large part
of the recent ref discussions, as you can currently get away with doing
something like
On Saturday, June 01, 2013 23:41:32 monarch_dodra wrote:
> On Saturday, 1 June 2013 at 21:02:44 UTC, Jonathan M Davis wrote:
> > On Saturday, June 01, 2013 21:59:18 monarch_dodra wrote:
> >> The way I understood it, @safe defines a list of things that
> >> are
> >> or aren't legal inside the implem
On Sunday, June 02, 2013 00:04:18 monarch_dodra wrote:
> On Saturday, 1 June 2013 at 21:45:18 UTC, Andrei Alexandrescu
>
> wrote:
> > On 6/1/13 3:59 PM, monarch_dodra wrote:
> >> Yeah, overall, I'm confused as to what "@safe" means from an
> >> interface
> >> point of view :(
> >
> > If you call
On Saturday, 1 June 2013 at 21:45:18 UTC, Andrei Alexandrescu
wrote:
On 6/1/13 3:59 PM, monarch_dodra wrote:
Yeah, overall, I'm confused as to what "@safe" means from an
interface
point of view :(
If you call the function from a program with memory integrity
and it returns, it hasn't comprom
On Saturday, June 01, 2013 23:45:59 Maxim Fomin wrote:
> On Saturday, 1 June 2013 at 21:41:40 UTC, Jonathan M Davis wrote:
> > They're guaranteed to not introduce any such behavior. They
> > can't possibly
> > make any guarantees if the caller did @system operations and
> > passed a bad
> > pointer
On Saturday, 1 June 2013 at 21:46:01 UTC, Maxim Fomin wrote:
Updated example from above to show how @safe can introduce UB.
void main() @safe
{
int[4] y;
foo(y);
}
I believe that's a compiler bug.
@safe requires:
- No taking the address of a local variable or function parameter.
A slic
On Saturday, 1 June 2013 at 21:41:40 UTC, Jonathan M Davis wrote:
They're guaranteed to not introduce any such behavior. They
can't possibly
make any guarantees if the caller did @system operations and
passed a bad
pointer to the @safe function. But if all of the functions in
the call stack
are
On 6/1/13 3:59 PM, monarch_dodra wrote:
Yeah, overall, I'm confused as to what "@safe" means from an interface
point of view :(
If you call the function from a program with memory integrity and it
returns, it hasn't compromised the memory integrity of that program.
Homework: define memory in
Am 01.06.2013 23:34, schrieb Peter Alexander:
On Saturday, 1 June 2013 at 21:02:44 UTC, Jonathan M Davis wrote:
@safe is for memory safety, meaning that @safe code cannot corrupt
memory. You
can get segfaults due to null pointers and the like, but you can't
have code
which writes passed the end
On Saturday, 1 June 2013 at 21:02:44 UTC, Jonathan M Davis wrote:
On Saturday, June 01, 2013 21:59:18 monarch_dodra wrote:
The way I understood it, @safe defines a list of things that
are
or aren't legal inside the implementation of a function. It
also
changes the scheme of bounds checking, in
On Saturday, June 01, 2013 23:34:09 Peter Alexander wrote:
> On Saturday, 1 June 2013 at 21:02:44 UTC, Jonathan M Davis wrote:
> > @safe is for memory safety, meaning that @safe code cannot
> > corrupt memory. You
> > can get segfaults due to null pointers and the like, but you
> > can't have code
On Saturday, 1 June 2013 at 21:02:44 UTC, Jonathan M Davis wrote:
@safe is for memory safety, meaning that @safe code cannot
corrupt memory. You
can get segfaults due to null pointers and the like, but you
can't have code
which writes passed the end of a buffer, or which uses a freed
memory, or
On Saturday, 1 June 2013 at 20:31:45 UTC, monarch_dodra wrote:
On Saturday, 1 June 2013 at 20:22:01 UTC, Nick Sabalausky wrote:
Core dumps aren't the big problem @safe tries to avoid. The
big problem
is memory corruption, ie trampling memory you didn't expect to
(or
shouldn't be allowed to).
On Saturday, June 01, 2013 21:59:18 monarch_dodra wrote:
> The way I understood it, @safe defines a list of things that are
> or aren't legal inside the implementation of a function. It also
> changes the scheme of bounds checking, in release code.
>
> What bothers me though, is that from an inter
On Saturday, 1 June 2013 at 19:59:19 UTC, monarch_dodra wrote:
The way I understood it, @safe defines a list of things that
are or aren't legal inside the implementation of a function. It
also changes the scheme of bounds checking, in release code.
You completely get the point. Safe attribute
On Saturday, 1 June 2013 at 20:22:01 UTC, Nick Sabalausky wrote:
On Sat, 01 Jun 2013 21:59:18 +0200
"monarch_dodra" wrote:
The way I understood it, @safe defines a list of things that
are or aren't legal inside the implementation of a function.
It also changes the scheme of bounds checking, i
On Sat, 01 Jun 2013 21:59:18 +0200
"monarch_dodra" wrote:
> The way I understood it, @safe defines a list of things that are
> or aren't legal inside the implementation of a function. It also
> changes the scheme of bounds checking, in release code.
>
> What bothers me though, is that from an
The way I understood it, @safe defines a list of things that are
or aren't legal inside the implementation of a function. It also
changes the scheme of bounds checking, in release code.
What bothers me though, is that from an interface point of view,
it doesn't really mean anything (or at leas
23 matches
Mail list logo
