On 29.05.19 18:37, Valeriy Fedotov wrote:
In my point of view @trusted means "I use pointer-related operations
correctly. Also I am using all @system interfaces correctly".
@trusted means: "This function is as safe as an @safe function. But the
compiler doesn't verify the implementation." Whet
On Monday, 27 May 2019 at 14:26:16 UTC, ag0aep6g wrote:
Oh, yeah. Getting @trusted right is hard. Getting it right when
user-provided types are involved is extra hard, because you
can't even trust fundamental operations like assignment or
copying.
In my point of view @trusted means "I use poi
On 27.05.19 15:34, Atila Neves wrote:
It's ugly but would work. Right now I don't think I can do any better
than to follow your suggestion, but I predict many beard-stroking walks
for me along Lake Geneva in the near future.
Oh, yeah. Getting @trusted right is hard. Getting it right when
user
On Monday, 27 May 2019 at 10:31:10 UTC, ag0aep6g wrote:
On 27.05.19 12:06, Atila Neves wrote:
No, and I guess it can't. I'm trying to figure out what the
implications are. Can Vector only be @safe for Mallocator? Is
it possible to write a @safe Vector at all without having to
force the allocat
On 27.05.19 12:06, Atila Neves wrote:
No, and I guess it can't. I'm trying to figure out what the implications
are. Can Vector only be @safe for Mallocator? Is it possible to write a
@safe Vector at all without having to force the allocator to be @safe?
For @safe allocators, Vector can be @saf
On Monday, 27 May 2019 at 10:01:15 UTC, Atila Neves wrote:
On Monday, 27 May 2019 at 09:07:48 UTC, Paolo Invernizzi wrote:
On Monday, 27 May 2019 at 08:54:45 UTC, Atila Neves wrote:
On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote:
Then there's the fact that if a 3rd party library reall
On Monday, 27 May 2019 at 09:48:27 UTC, ag0aep6g wrote:
On 27.05.19 10:54, Atila Neves wrote:
I don't see the problem here. This example would throw
RangeError at runtime instead of actually overwriting memory
unless bounds checking is turned off.
No, it doesn't. It's a complete, runnable exa
On Monday, 27 May 2019 at 09:07:48 UTC, Paolo Invernizzi wrote:
On Monday, 27 May 2019 at 08:54:45 UTC, Atila Neves wrote:
On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote:
Then there's the fact that if a 3rd party library really does
want to corrupt memory they can just tag all their f
On 27.05.19 10:54, Atila Neves wrote:
I don't see the problem here. This example would throw RangeError at
runtime instead of actually overwriting memory unless bounds checking is
turned off.
No, it doesn't. It's a complete, runnable example. You can try it at
home. It does overwrite `foo` an
On Monday, 27 May 2019 at 08:54:45 UTC, Atila Neves wrote:
On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote:
Then there's the fact that if a 3rd party library really does
want to corrupt memory they can just tag all their functions
with @trusted, and unless someone looks at their code n
On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote:
On 24.05.19 18:19, Atila Neves wrote:
On Friday, 24 May 2019 at 13:30:05 UTC, ag0aep6g wrote:
[...]
My `puts`s might not do any harm, but they could just as well
be buffer overflows.
Could you please give an example of how @system alloc
On Friday, 24 May 2019 at 11:41:12 UTC, Atila Neves wrote:
I'd been holding off on announcing this until DIP1008 actually
got implemented, and now it has:
https://code.dlang.org/packages/nogc
This dub package has a @nogc version of `std.conv.text` (which
probably isn't as good yet) that, inst
On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote:
On 24.05.19 18:19, Atila Neves wrote:
On Friday, 24 May 2019 at 13:30:05 UTC, ag0aep6g wrote:
[...]
My `puts`s might not do any harm, but they could just as well
be buffer overflows.
Could you please give an example of how @system alloc
On 24.05.19 18:51, ag0aep6g wrote:
char[3] buf;
[...]
buf.ptr[i .. i + 3] = '!';
[...]
UnsafeAllocator.instance.i = 8;
/* greater than buf.length, whoops */
Actually, anything greater than zero is a whoops, of course.
On 24.05.19 18:19, Atila Neves wrote:
On Friday, 24 May 2019 at 13:30:05 UTC, ag0aep6g wrote:
[...]
My `puts`s might not do any harm, but they could just as well be
buffer overflows.
Could you please give an example of how @system allocator code could do
that?
Sure. You just write beyond s
On Friday, 24 May 2019 at 13:30:05 UTC, ag0aep6g wrote:
On Friday, 24 May 2019 at 13:13:12 UTC, Atila Neves wrote:
Thanks for this. I think the only violation is calling
`stringz` on `Z`, and that was due to a poorly designed DbI
check on being able to call `stringz`. Allocating generally
isn'
On Friday, 24 May 2019 at 13:13:12 UTC, Atila Neves wrote:
Thanks for this. I think the only violation is calling
`stringz` on `Z`, and that was due to a poorly designed DbI
check on being able to call `stringz`. Allocating generally
isn't @system, and freeing is ok to trust since vector is
ta
On Friday, 24 May 2019 at 12:32:45 UTC, ag0aep6g wrote:
On 24.05.19 13:41, Atila Neves wrote:
[...]
You've got safety violations:
/+ dub.sdl:
name "test"
dependency "nogc" version="~>0.5.0"
+/
import core.stdc.stdio: puts;
struct S1
{
S2 s2;
this(ref const S1 src) const
On 24.05.19 13:41, Atila Neves wrote:
I'd been holding off on announcing this until DIP1008 actually got
implemented, and now it has:
https://code.dlang.org/packages/nogc
You've got safety violations:
/+ dub.sdl:
name "test"
dependency "nogc" version="~>0.5.0"
+/
import core.st
On Friday, 24 May 2019 at 11:41:12 UTC, Atila Neves wrote:
I'd been holding off on announcing this until DIP1008 actually
got implemented, and now it has:
[...]
Awesome!!
Now we just need to get to compile Druntime and Phobos with
-preview=dip1008, s.t. we can enable it by default :)
See
I'd been holding off on announcing this until DIP1008 actually
got implemented, and now it has:
https://code.dlang.org/packages/nogc
This dub package has a @nogc version of `std.conv.text` (which
probably isn't as good yet) that, instead of returning a `string`
returns an `automem.vector.Vect
21 matches
Mail list logo
