I haven't examined that particular issue, but @trusted applies to things with a
SAFE INTERFACE. Just sticking it on any old system function does not work. For
example, declaring strlen() to be @trusted is a giant mistake, because it's
interface is not safe.
On 2/5/2017 1:44 PM, Jakub Łabaj via phobos wrote:
There is an idea to make stdio.readf @trusted/@safe (reported here:
https://issues.dlang.org/show_bug.cgi?id=8471). What currently makes it unsafe
is LockingTextReader using functions FLOCK, FUNLOCK, FGETC (aliased from extern
functions, dependent on the OS) and using a cast from 'shared(_IO_FILE)*' to
'_IO_FILE*'.
I found out that stdio.write* functions are made @safe by declaring all methods
of LockingTextWriter (similar to LockingTextReader) @trusted and using helper
function:
/**
* Property used by writeln/etc. so it can infer @safe since stdout is
__gshared
*/
private @property File trustedStdout() @trusted
{
return stdout;
}
So the obvious solution is to copy the approach of stdio.write. The other one
would be to mark underlying functions FLOCK/FUNLOCK/FGETC @trusted (which in the
process would allow to get rid off @trusted from LockingTextWriter, except
casting from shared), but I'm not sure if it's legit as there may be some quirks
and they should not be @trusted at all.
So my question are: are both solutions presented acceptable? If yes, which one
is preferred? Or maybe there is a better one?
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
