Ouch, yes, I meant fgetc_unlocked.

Thank you for the help! As a solution I'm going to make a PR with the mentioned changes, i.e. copy the approach of writef and apply @trusted to LockingTextReader - I think I can do this, because its behaviour ensures that functions FGETC, FLOCK, FUNLOCK are invoked in a safe manner.

On Tuesday, 7 February 2017 at 20:04:51 UTC, Andrei Alexandrescu wrote:
> 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

Here some research is necessary. What I did e.g. was to google for:

is fgetc_unlocked safe?

and got a bunch of answers, til I got to https://www.gnu.org/software/libc/manual/html_node/Character-Input.html which in turns links to "POSIX Safety Concepts" i.e. https://www.gnu.org/software/libc/manual/html_node/POSIX-Safety-Concepts.html. That document sure doesn't mince words:

"MT-Unsafe, AS-Unsafe, AC-Unsafe functions are not safe to call within the safety contexts described above. Calling them within such contexts invokes undefined behavior."

So... the *_unlocked functions are not safe. They may be, however, wrapped in trusted functions (that issue the appropriate locking).


Andrei

On 02/07/2017 03:19 PM, Jakub Łabaj via phobos wrote:
> Ouch, yes, I meant fgetc_unlocked.
>
> Thank you for the help! As a solution I'm going to make a PR with the
> mentioned changes, i.e. copy the approach of writef and apply @trusted
> to LockingTextReader - I think I can do this, because its behaviour
> ensures that functions FGETC, FLOCK, FUNLOCK are invoked in a safe manner.
>
> On Tuesday, 7 February 2017 at 20:04:51 UTC, Andrei Alexandrescu wrote:
>> 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
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

LockingTextReader does exactly so - locks in constructor, unlocks in destructor and sometimes calls fgetc_unlocked. This makes it a good candidate for @trusted I believe.

On Tuesday, 7 February 2017 at 21:37:49 UTC, Andrei Alexandrescu wrote:
> Here some research is necessary. What I did e.g. was to google for:
>
> is fgetc_unlocked safe?
>
> and got a bunch of answers, til I got to https://www.gnu.org/software/libc/manual/html_node/Character-Input.html which in turns links to "POSIX Safety Concepts" i.e. https://www.gnu.org/software/libc/manual/html_node/POSIX-Safety-Concepts.html. That document sure doesn't mince words:
>
> "MT-Unsafe, AS-Unsafe, AC-Unsafe functions are not safe to call within the safety contexts described above. Calling them within such contexts invokes undefined behavior."
>
> So... the *_unlocked functions are not safe. They may be, however, wrapped in trusted functions (that issue the appropriate locking).
>
>
> Andrei
>
> On 02/07/2017 03:19 PM, Jakub Łabaj via phobos wrote:
>> Ouch, yes, I meant fgetc_unlocked.
>>
>> Thank you for the help! As a solution I'm going to make a PR with the
>> mentioned changes, i.e. copy the approach of writef and apply @trusted
>> to LockingTextReader - I think I can do this, because its behaviour
>> ensures that functions FGETC, FLOCK, FUNLOCK are invoked in a safe manner.
>>
>> On Tuesday, 7 February 2017 at 20:04:51 UTC, Andrei Alexandrescu wrote:
>>> 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


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