as etc.c.zlib is just an interface to C code, everything there should be marked "nothrow".
and, for that reason, "@trusted" too, 'cause ZLib tries hard to validate it's input data.
(In reply to Steven Schveighoffer from comment #2)
> PR does not mark everything @trusted, that is not a good idea. So that part
> is WONTFIX. nothrow is correct.
i'd prefer it to have `@trusted` too, but... ok, it's not an issue, i can mark my wrappers `@trusted` instead. thanks. ;-)
Comment #5 by dfj1esp02 — 2016-06-22T10:13:58Z
Are you sure it can survive if someone messes with z_stream fields? They are all public.
Comment #6 by ketmar — 2016-06-22T18:37:32Z
my understanding of @trusted (and @safe, for that matter) is that safety promise is nullified if someone passing invalid pointer to such functions. like, pass a slice created from arbitrary memory region to @safe function, and it *will* segfault.
zlib stream functions holds the very same promise: until the passed pointers and sizes are valid, zlib will neither crash nor corrupt memory outsize the specified range. that's why i thought that it can be marked @trusted (and actulally does so in my own code).
Comment #7 by ketmar — 2016-06-22T18:41:09Z
i.e. i always thought that @trusted code should survive external errors (like courrupted data), and does check for null pointers, etc. but no code can validate all invalid arguments passed by caller. there is no way to know if passed pointer and length, for example, is absolutely valid. and if i'll change `.ptr` field of delegate with closure, for example (it is publicly available, and i can mess with it), and then pass that delegate to @safe... KABOOM. so i'm pretty sure that my understanding is correct. actually, i'm so sure that there is absolutely no reason in trying to change my mind on that. ;-)
Comment #8 by schveiguy — 2016-06-23T13:16:00Z
@trusted means that the call should be considered @safe, but it must call some @system functions internally. However, the marking means that the @system calls are properly encapsulated such that the total call is @safe.
If we marked zlib @trusted, then we would be responsible for verifying all the code is actually @safe.
You are right that if you pass invalid data into a safe function, guarantees are lost. But we don't need to go there to prove the library is unsafe: the zalloc and zfree functions can do anything, and the library can call them whenever they need data. So right there, you can't mark it @trusted.
Comment #9 by ketmar — 2016-06-23T13:32:24Z
ah, i completely forgot that zlib is allocating memory internally! yes, i was wrong, in this case we can't mark it @trusted.
Comment #10 by dfj1esp02 — 2016-06-23T16:09:42Z
(In reply to Ketmar Dark from comment #6)
> my understanding of @trusted (and @safe, for that matter) is that safety
> promise is nullified if someone passing invalid pointer to such functions.
That only applies to a @system caller, a @safe caller can't come up with an invalid pointer, but it still can mess with data in other ways, if a @trusted callee can't handle it, it means it has an unsafe interface.
Comment #11 by ketmar — 2016-06-23T16:54:45Z
sure it can.
int n;
auto dg = delegate () { return n+42; };
dg.ptr = cast(void*)42;
safeFunction(dg);
Comment #12 by ag0aep6g — 2016-06-23T17:52:55Z
(In reply to Sobirari Muhomori from comment #10)
> a @safe caller can't come up with an
> invalid pointer
(In reply to Ketmar Dark from comment #11)
> sure it can.
[...]
> dg.ptr = cast(void*)42;
That doesn't compile with @safe.
Comment #13 by ketmar — 2016-06-23T17:56:25Z
assign to .ptr no. but you *can* call the @safe code from unsafe with invalid pointer, what i was trying to show. essentially, @safe code can *end* *up* with invalid pointer, 'cause it was invoked with it.
Comment #14 by ag0aep6g — 2016-06-23T18:08:01Z
(In reply to Ketmar Dark from comment #13)
> assign to .ptr no. but you *can* call the @safe code from unsafe with
> invalid pointer, what i was trying to show.
I think that's agreed upon. In that case, all guarantees are out the window.
But @safe/@trusted functions must be memory-safe when called from other @safe functions with non-garbage arguments.
For example, functions that take a pointer and a length separately can't be @safe/@trusted, because an @safe caller can mess up the length.
So can't just mark arbitrary C functions @trusted without checking what they do.
Comment #15 by ketmar — 2016-06-23T18:38:46Z
[i]>I think that's agreed upon.[/i]
yep. and i recognized my mistake -- forgetting that zlib does memory allocation, which is can be @safe/@trusted by definition.
Comment #16 by ketmar — 2016-06-23T18:39:06Z
"can't be safe", of course ;-)
Comment #17 by github-bugzilla — 2016-10-01T11:45:51Z