Re: nogc v0.5.0 - DIP1008 works!

2019-05-29 Thread ag0aep6g via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-29 Thread Valeriy Fedotov via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread ag0aep6g via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread Atila Neves via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread ag0aep6g via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread Paolo Invernizzi via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread Atila Neves via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread Atila Neves via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread ag0aep6g via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread Paolo Invernizzi via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread Atila Neves via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-24 Thread Mike Franklin via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-24 Thread Meta via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-24 Thread ag0aep6g via Digitalmars-d-announce
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.

Re: nogc v0.5.0 - DIP1008 works!

2019-05-24 Thread ag0aep6g via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-24 Thread Atila Neves via Digitalmars-d-announce
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'

Re: nogc v0.5.0 - DIP1008 works!

2019-05-24 Thread ag0aep6g via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-24 Thread Atila Neves via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-24 Thread ag0aep6g via Digitalmars-d-announce
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

Re: nogc v0.5.0 - DIP1008 works!

2019-05-24 Thread Seb via Digitalmars-d-announce
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

nogc v0.5.0 - DIP1008 works!

2019-05-24 Thread Atila Neves via Digitalmars-d-announce
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