The title really does says it all. I keep copying OS function declarations into my code, just so I can add those attributes to them. Otherwise I simply cannot call "signalfd" and "sigemptyset" (to name a couple from my most recent history) from @safe code.

I can try and set up a PR when I have the time. If anyone else wants to take an easy one before then, you're welcome to :-)

Shachar

On 07/25/2017 03:50 PM, Shachar Shemesh wrote:
> The title really does says it all. I keep copying OS function declarations into my code, just so I can add those attributes to them. Otherwise I simply cannot call "signalfd" and "sigemptyset" (to name a couple from my most recent history) from @safe code.

Not all OS functions can be `@trusted`.

I don't about `signalfd` and `sigemptyset`, but `read` [1] can't be `@trusted`, for example. It takes pointer and length separately, and the pointer is a `void*`. That's not safe at all.


[1] http://man7.org/linux/man-pages/man2/read.2.html

On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote:
> The title really does says it all. I keep copying OS function declarations into my code, just so I can add those attributes to them. Otherwise I simply cannot call "signalfd" and "sigemptyset" (to name a couple from my most recent history) from @safe code.
>
> I can try and set up a PR when I have the time. If anyone else wants to take an easy one before then, you're welcome to :-)
>
> Shachar

these functions are supposed to have trused wrappers if used in safe code.

On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote:
> The title really does says it all.

Since you explicitly state *all* OS functions:
nothrow: Should be OK (only callbacks could violate this and they should be nothrow, anyway).
@trusted: This can only be done for those functions that don't take arguments open to memory corruption. Take a look at POSIX read, it can never be trusted (same as any C function taking pointer+length of pointed to).
@nogc: This can only be done for those functions that are statically known to never call a D callback that's not also @nogc. Take a look at pthread_create vor pthread_join, they can never be @nogc, because that would mean threads may never allocate with the GC.

> I keep copying OS function declarations into my code, just so I can add those attributes to them. Otherwise I simply cannot call "signalfd" and "sigemptyset" (to name a couple from my most recent history) from @safe code.

---
auto result = () @trusted { return systemFunction(...) }();
---

On 25/07/17 17:12, Stefan Koch wrote:
> On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote:
>> The title really does says it all. I keep copying OS function declarations into my code, just so I can add those attributes to them. Otherwise I simply cannot call "signalfd" and "sigemptyset" (to name a couple from my most recent history) from @safe code.
>>
>> I can try and set up a PR when I have the time. If anyone else wants to take an easy one before then, you're welcome to :-)
>>
>> Shachar
> 
> these functions are supposed to have trused wrappers if used in safe code.

I'd love to hear the difference between:
extern(C) int signalfd (int __fd, const(sigset_t)* __mask, int __flags) nothrow @nogc;

and
int signalfdWrapper(int __fd, const(sigset_t)* __mask, int __flags) nothrow @trusted @nogc {
	return signalfd(__fd, __mask, __flags);
}

Or are you suggesting the wrapper do something else?

Shachar

On 25/07/17 17:11, ag0aep6g wrote:
> On 07/25/2017 03:50 PM, Shachar Shemesh wrote:
>> The title really does says it all. I keep copying OS function declarations into my code, just so I can add those attributes to them. Otherwise I simply cannot call "signalfd" and "sigemptyset" (to name a couple from my most recent history) from @safe code.
> 
> Not all OS functions can be `@trusted`.
> 
> I don't about `signalfd` and `sigemptyset`, but `read` [1] can't be `@trusted`, for example. It takes pointer and length separately, and the pointer is a `void*`. That's not safe at all.

And, indeed, the code calling "read" shouldn't be able to do that as @safe. Read itself, however, is trusted (because, let's face it, if you cannot trust the kernel, you're screwed anyways).

Having said that, I have no objection to excluding the "pointer+length" system calls from the above rule. They are, by far, the minority of system calls.

Shachar

On 25/07/17 17:24, Moritz Maxeiner wrote:
> On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote:
>> The title really does says it all.
> 
> Since you explicitly state *all* OS functions:
> nothrow: Should be OK (only callbacks could violate this and they should be nothrow, anyway).
Technically, any system call that is a pthreads cancellation point may throw a C++ exception.

If we go down that route, however, calling system calls from nothrow becomes completely impossible, which is another way of saying that decorating just about anything with nothrow becomes impossible.

> @trusted: This can only be done for those functions that don't take arguments open to memory corruption. Take a look at POSIX read, it can never be trusted (same as any C function taking pointer+length of pointed to).
> @nogc: This can only be done for those functions that are statically known to never call a D callback that's not also @nogc. Take a look at pthread_create vor pthread_join, they can never be @nogc, because that would mean threads may never allocate with the GC.

The decoration's situation with callbacks is pretty horrible throughout D. I'm not sure this is the most compelling argument, however. The function passed to pthread_create does not, logically, run in the pthread_create function. As such, I don't think this logic holds.

As for pthread_join, I have no idea what you meant by it. Please elaborate why you think it is a problem.

> 
> ---
> auto result = () @trusted { return systemFunction(...) }();
> ---

Care to explain how to adapt that neat trick for "nothrow" and "@nogc"?

Shachar

On 07/25/2017 04:32 PM, Shachar Shemesh wrote:
> And, indeed, the code calling "read" shouldn't be able to do that as @safe. Read itself, however, is trusted (because, let's face it, if you cannot trust the kernel, you're screwed anyways).

That's not how `@trusted` works. The point of `@trusted` is to allow unsafe features in the implementation. The interface must be just as safe as with `@safe`.

`read` doesn't have a safe interface. `read` is safe as long as long as you pass good arguments. When you pass bad arguments, `read` will break your stuff. A `@trusted` function must always be safe, no matter the arguments.

On Tuesday, 25 July 2017 at 14:32:18 UTC, Shachar Shemesh wrote:
> On 25/07/17 17:11, ag0aep6g wrote:
>> On 07/25/2017 03:50 PM, Shachar Shemesh wrote:
>>> The title really does says it all. I keep copying OS function declarations into my code, just so I can add those attributes to them. Otherwise I simply cannot call "signalfd" and "sigemptyset" (to name a couple from my most recent history) from @safe code.
>> 
>> Not all OS functions can be `@trusted`.
>> 
>> I don't about `signalfd` and `sigemptyset`, but `read` [1] can't be `@trusted`, for example. It takes pointer and length separately, and the pointer is a `void*`. That's not safe at all.
>
> And, indeed, the code calling "read" shouldn't be able to do that as @safe. Read itself, however, is trusted

No, it is not, because it does not fulfill the definition of @trusted (callable from *any* @safe context without allowing memory corruption).

> (because, let's face it, if you cannot trust the kernel, you're screwed anyways).

This has nothing to do with trusting the kernel:
---
char[1] buf;
int dontCorruptMePlease;
read(fd, &buf[0], 10);
---
The read implementation can't verify the buffer size, it must assume it to be correct. If it's too large  for the actual buffer -> memory corruption.
No function taking pointer+size of pointed to (that accesses them) can be @trusted.

> Having said that, I have no objection to excluding the "pointer+length" system calls from the above rule. They are, by far, the minority of system calls.

And also happen to be the most used ones.
But I digress, the point is *every single functionust be verified for every single Attribute* (other than nothrow).
PRs are welcome :)

On 7/25/17 10:27 AM, Shachar Shemesh wrote:
> On 25/07/17 17:12, Stefan Koch wrote:
>> On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote:
>>> The title really does says it all. I keep copying OS function declarations into my code, just so I can add those attributes to them. Otherwise I simply cannot call "signalfd" and "sigemptyset" (to name a couple from my most recent history) from @safe code.
>>>
>>> I can try and set up a PR when I have the time. If anyone else wants to take an easy one before then, you're welcome to :-)
>>>
>>> Shachar
>>
>> these functions are supposed to have trused wrappers if used in safe code.
> 
> I'd love to hear the difference between:
> extern(C) int signalfd (int __fd, const(sigset_t)* __mask, int __flags) nothrow @nogc;
> 
> and
> int signalfdWrapper(int __fd, const(sigset_t)* __mask, int __flags) nothrow @trusted @nogc {
>      return signalfd(__fd, __mask, __flags);
> }

I think signalfd can be marked @trusted, as @safe code supports pointing at a single element.

Other system calls that accept a pointer/length combo cannot be marked @trusted.

-Steve