[phobos] Making std.stdio.readf @safe

[Jakub Łabaj via phobos]

On Tuesday, 7 February 2017 at 11:41:44 UTC, Walter Bright wrote:
> 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
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos

Ok, so I have doubts whether these functions can be @trusted. On 
the one hand they get just FILE* as an argument which (as I see 
it) makes it safe interface. On the other hand FGETC is unlocked 
version of fgetc and requires explicit lock to be used safely; 
FLOCK and FUNLOCK invocations should match, therefore there is 
also possibility to use it incorrectly. Personally I would not 
mark them @trusted then, is it correct?