February 07, 2017 Re: [phobos] Making std.stdio.readf @safe | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
February 07, 2017 Re: [phobos] Making std.stdio.readf @safe | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jakub Łabaj | 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 |
February 07, 2017 Re: [phobos] Making std.stdio.readf @safe | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
Copyright © 1999-2021 by the D Language Foundation