Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
Don wrote:
Andrei Alexandrescu wrote:
module(safe) is not a comment. We need three types of modules because
of the interaction between what the module declares and what the
command line wants.
Let's assume the default, no-flag build allows unsafe code, like
right now. Then, module(safe) means that the module volunteers itself
for tighter checking, and module(system) is same as module unadorned.
But then if the user compiles with -safe, module(safe) is the same as
module unadorned, and module(system) allows for unchecked operations
in that particular module. I was uncomfortable with this, but Walter
convinced me that D's charter is not to allow sandbox compilation and
execution of malicious code. If you have the sources, you may as well
take a look at their module declarations if you have some worry.
Regardless on the result of the debate regarding the default
compilation mode, if the change of that default mode is allowed in
the command line, then we need both module(safe) and module(system).
When would it be MANDATORY for a module to be compiled in safe mode?
module(safe) entails safe mode, come hell or high water.
If module(safe) implies bound-checking *cannot* be turned off for that
module, would any standard library modules be module(safe)?
I think most or all of the standard library is trusted. But don't forget
that std is a bad example of a typical library or program because std
interfaces programs with the OS.
I think it's not so atypical. Database, graphics, anything which calls a
C library will be the same.
For an app, I'd imagine you'd have a policy of either always compiling
with -safe, or ignoring it.
If you've got a general-purpose library, you have to assume some of your
users will be compiling with -safe. So you have to make all your library
modules safe, regardless of how they are marked. (Similarly, -w is NOT
optional for library developers).
That doesn't leave very much.
I'm not seeing the use case for module(safe).
