www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - vibe.d: problematic "Non- safe methods are deprecated in REST

reply Piotr Mitana <the.mail.of.mi2 gmail.com> writes:
Hello,

I've recently started building a little REST application on 
vibe.d. I decided to use the "database" library, as I need to 
communicate with the PostgreSQL instance.

During the compilation I see the deprecation warning:
"Non- safe methods are deprecated in REST interfaces"

So two questions rise:

1. Will non- safe methods in REST be disallowed someday?
2. Isn't it too restrictive? If it IS to be disallowed someday, I 
just won't be able to call most libraries from REST, as I expect 
the database library for example is definitely not  safe and 
cannot be.

If I post in the wrong forum, please drop me a line where should 
I post instead.
Jul 10 2018
parent reply WebFreak001 <d.forum webfreak.org> writes:
On Tuesday, 10 July 2018 at 13:14:24 UTC, Piotr Mitana wrote:

 Hello,

 I've recently started building a little REST application on 
 vibe.d. I decided to use the "database" library, as I need to 
 communicate with the PostgreSQL instance.

 During the compilation I see the deprecation warning:
 "Non- safe methods are deprecated in REST interfaces"

 So two questions rise:

 1. Will non- safe methods in REST be disallowed someday?
 2. Isn't it too restrictive? If it IS to be disallowed someday, 
 I just won't be able to call most libraries from REST, as I 
 expect the database library for example is definitely not  safe 
 and cannot be.

 If I post in the wrong forum, please drop me a line where 
 should I post instead.


It's supposed to make webservers safe and not crash because of 
segmentation faults, etc.

If you still want to write code like you are used to and don't 
care about that in your webserver, just mark everything in the 
implementation  trusted (but  safe in the interface) and it will 
be fine.
Jul 10 2018
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, 10 July 2018 07:24:43 MDT WebFreak001 via Digitalmars-d-learn 
wrote:

 On Tuesday, 10 July 2018 at 13:14:24 UTC, Piotr Mitana wrote:

 Hello,

 I've recently started building a little REST application on
 vibe.d. I decided to use the "database" library, as I need to
 communicate with the PostgreSQL instance.

 During the compilation I see the deprecation warning:
 "Non- safe methods are deprecated in REST interfaces"

 So two questions rise:

 1. Will non- safe methods in REST be disallowed someday?
 2. Isn't it too restrictive? If it IS to be disallowed someday,
 I just won't be able to call most libraries from REST, as I
 expect the database library for example is definitely not  safe
 and cannot be.

 If I post in the wrong forum, please drop me a line where
 should I post instead.


 It's supposed to make webservers safe and not crash because of
 segmentation faults, etc.

 If you still want to write code like you are used to and don't
 care about that in your webserver, just mark everything in the
 implementation  trusted (but  safe in the interface) and it will
 be fine.


Ideally, in general, any  system code should be verified as  trusted and
mark with  trusted in the narrowest piece of code possible. Having higher
level functions be  system usually means that no attempt was made to make it
 safe, so it's unlikely to have been verified for memory safety and
definitely risks having memory problems.

Now, whether vibe.d needs to insist on it, I don't know, but if it does,
then its API can be  safe, and any code using it can rely on it being  safe,
whereas if that interface does not require  safe, then the  safety depends
on the specific implementation, and the code using it is likely either
forced to use  trusted without actually verifying that the code is  safe
(which is not good) or to give up on  safe. In general,  system interfaces
are a terrible idea if you want to be able to use  safe. Unless the
interface itself is doing something that is clearly  system regardless of
the actual implementation, the  system aspects generally are a detail of the
implementation, and the programmer writing it should be manually verifying
it for  safety and using  trusted where appropriate (preferably as narrowly
as possible so that as much of the checking as possible is left up to the
compiler).

Of course, if you don't want to bother with  safe or verifying your code for
 safety, then having an  safe interface with an implementation using  system
features can be pretty annoying, but with any program of real size,  safety
can become extremely important, and vibe.d is definitely aimed at being used
in serious production code where it's going to matter.

- Jonathan M Davis
Jul 10 2018
prev sibling parent reply Piotr Mitana <the.mail.of.mi2 gmail.com> writes:
On Tuesday, 10 July 2018 at 13:24:43 UTC, WebFreak001 wrote:

 It's supposed to make webservers safe and not crash because of 
 segmentation faults, etc.

 If you still want to write code like you are used to and don't 
 care about that in your webserver, just mark everything in the 
 implementation  trusted (but  safe in the interface) and it 
 will be fine.


I understand the motivation of this and this motivation is 
undoubtly correct.

The problem is when you use the libraries, especially those 
interfacing with C code. The intention of  trusted is to use it 
to mark the code that *is* memory safe, but it cannot be verified 
automatically by the compiler (for example required checks are 
done before an array access).

That's why there is a problem with the libraries that are *not* 
safe - or at least I don't know the code and cannot verify that 
they are.
Jul 11 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, 11 July 2018 01:46:10 MDT Piotr Mitana via Digitalmars-d-learn 
wrote:

 On Tuesday, 10 July 2018 at 13:24:43 UTC, WebFreak001 wrote:

 It's supposed to make webservers safe and not crash because of
 segmentation faults, etc.

 If you still want to write code like you are used to and don't
 care about that in your webserver, just mark everything in the
 implementation  trusted (but  safe in the interface) and it
 will be fine.


 I understand the motivation of this and this motivation is
 undoubtly correct.

 The problem is when you use the libraries, especially those
 interfacing with C code. The intention of  trusted is to use it
 to mark the code that *is* memory safe, but it cannot be verified
 automatically by the compiler (for example required checks are
 done before an array access).

 That's why there is a problem with the libraries that are *not*
 safe - or at least I don't know the code and cannot verify that
 they are.


Well, you should be able to at least verify that your usage of the library
is  safe. The internals may have problems, but if you've verified all of
your code and marked it as  trusted, then the compiler can check the rest of
your code, and if there _is_ a memory corruption problem, you know where to
look - any  trusted code and then any libraries you're using. But if you
just give up and let all of your code be  system, then you lose out on all
of the benefits of the compiler verifying your code. The C binding in
druntime are typically marked with  trusted so long as their API is  safe
(and thus any  safety bugs in using it are inside the C implementation and
not due to misuing the function), since if we don't do that, then  safe
becomes pretty useless pretty fast in real world programs. At some point,
you have to trust that the C functions are doing their jobs properly, but
regardless of whether they are,  trusted allows you to narrow down the
problem when there is a memory corruption issue while allowing most of your
program to be verified by the compiler - which is the point.

- Jonathan M Davis
Jul 11 2018