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
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
