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@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

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@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/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@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?
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On 2/7/2017 6:00 AM, Jakub Łabaj via phobos wrote:
> 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?

I'd say you're right.
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

This may be hasty. https://linux.die.net/man/2/flock does not perform any unsafe operation, even for invalid arguments. -- Andrei

On 2/7/17 11:44 AM, Walter Bright via phobos wrote:
>
>
> On 2/7/2017 6:00 AM, Jakub Łabaj via phobos wrote:
>> 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?
>
> I'd say you're right.
> _______________________________________________
> phobos mailing list
> phobos@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On Tuesday, 7 February 2017 at 17:45:00 UTC, Andrei Alexandrescu wrote:
> This may be hasty. https://linux.die.net/man/2/flock does not perform any unsafe operation, even for invalid arguments. -- Andrei
>
> On 2/7/17 11:44 AM, Walter Bright via phobos wrote:
>>
>>
>> On 2/7/2017 6:00 AM, Jakub Łabaj via phobos wrote:
>>> 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?
>>
>> I'd say you're right.
>> _______________________________________________
>> phobos mailing list
>> phobos@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos

FLOCK is aliased (at Linux) to https://linux.die.net/man/3/flockfile .  It may be safe on its own, but to avoid deadlock must be followed by call to unlock. Does it qualify to be @trusted in such case?
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

Safe/trusted means "no unsafe operation", not "will cause issues if used incorrectly". -- Andrei

On 2/7/17 12:59 PM, Jakub Łabaj via phobos wrote:
> On Tuesday, 7 February 2017 at 17:45:00 UTC, Andrei Alexandrescu wrote:
>> This may be hasty. https://linux.die.net/man/2/flock does not perform
>> any unsafe operation, even for invalid arguments. -- Andrei
>>
>> On 2/7/17 11:44 AM, Walter Bright via phobos wrote:
>>>
>>>
>>> On 2/7/2017 6:00 AM, Jakub Łabaj via phobos wrote:
>>>> 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?
>>>
>>> I'd say you're right.
>>> _______________________________________________
>>> phobos mailing list
>>> phobos@puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>
> FLOCK is aliased (at Linux) to https://linux.die.net/man/3/flockfile .
> It may be safe on its own, but to avoid deadlock must be followed by
> call to unlock. Does it qualify to be @trusted in such case?
> _______________________________________________
> phobos mailing list
> phobos@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

What about fgetc_unlocked then? It may be not thread safe if used without lock, is it considered unsafe because of bad usage or just unsafe? Sorry, I still have some problems with identifying this.

On Tuesday, 7 February 2017 at 18:01:38 UTC, Andrei Alexandrescu wrote:
> Safe/trusted means "no unsafe operation", not "will cause issues if used incorrectly". -- Andrei
>
> On 2/7/17 12:59 PM, Jakub Łabaj via phobos wrote:
>> On Tuesday, 7 February 2017 at 17:45:00 UTC, Andrei Alexandrescu wrote:
>>> This may be hasty. https://linux.die.net/man/2/flock does not perform
>>> any unsafe operation, even for invalid arguments. -- Andrei
>>>
>>> On 2/7/17 11:44 AM, Walter Bright via phobos wrote:
>>>>
>>>>
>>>> On 2/7/2017 6:00 AM, Jakub Łabaj via phobos wrote:
>>>>> 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?
>>>>
>>>> I'd say you're right.
>>>> _______________________________________________
>>>> phobos mailing list
>>>> phobos@puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>> FLOCK is aliased (at Linux) to https://linux.die.net/man/3/flockfile .
>> It may be safe on its own, but to avoid deadlock must be followed by
>> call to unlock. Does it qualify to be @trusted in such case?
>> _______________________________________________
>> phobos mailing list
>> phobos@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos


_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

I see it like this:
- flockfile - can be @trusted, because no matter when we call it with correct argument, it won't do anything unsafe
- funlockfile - if called by not owning thread, the behaviour is undefined - so potentially may do something unsafe (I don't know what happens if called on not locked file, probably is ignored)
fgetc - when not guarded by lock it is not thread safe, shouldn't be @trusted

Is my reasoning correct? In such case having only one of these functions @trusted doesn't solve the problem which means I would need to make methods of LockingTextReader @trusted.

On Tuesday, 7 February 2017 at 18:08:42 UTC, Jakub Łabaj wrote:
> What about fgetc_unlocked then? It may be not thread safe if used without lock, is it considered unsafe because of bad usage or just unsafe? Sorry, I still have some problems with identifying this.
>
> On Tuesday, 7 February 2017 at 18:01:38 UTC, Andrei Alexandrescu wrote:
>> Safe/trusted means "no unsafe operation", not "will cause issues if used incorrectly". -- Andrei
>>
>> On 2/7/17 12:59 PM, Jakub Łabaj via phobos wrote:
>>> On Tuesday, 7 February 2017 at 17:45:00 UTC, Andrei Alexandrescu wrote:
>>>> This may be hasty. https://linux.die.net/man/2/flock does not perform
>>>> any unsafe operation, even for invalid arguments. -- Andrei
>>>>
>>>> On 2/7/17 11:44 AM, Walter Bright via phobos wrote:
>>>>>
>>>>>
>>>>> On 2/7/2017 6:00 AM, Jakub Łabaj via phobos wrote:
>>>>>> 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?
>>>>>
>>>>> I'd say you're right.
>>>>> _______________________________________________
>>>>> phobos mailing list
>>>>> phobos@puremagic.com
>>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>
>>> FLOCK is aliased (at Linux) to https://linux.die.net/man/3/flockfile .
>>> It may be safe on its own, but to avoid deadlock must be followed by
>>> call to unlock. Does it qualify to be @trusted in such case?
>>> _______________________________________________
>>> phobos mailing list
>>> phobos@puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos


_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On 2/7/17 2:07 PM, Jakub Łabaj via phobos wrote:
> I see it like this:
> - flockfile - can be @trusted, because no matter when we call it with
> correct argument, it won't do anything unsafe

affirmative

> - funlockfile - if called by not owning thread, the behaviour is
> undefined - so potentially may do something unsafe (I don't know what
> happens if called on not locked file, probably is ignored)

affirmative - in C "undefined" implies "unsafe"

> fgetc - when not guarded by lock it is not thread safe, shouldn't be
> @trusted

I think you mean fgetc_unlocked? fgetc issues its own locking and unlocking.


Andrei
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos