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