From ae313cef93e940464d0a615ebb142f1057e0c529 Mon Sep 17 00:00:00 2001 From: Sinatra Date: Fri, 5 Jun 2015 10:54:02 -0400 Subject: [PATCH] Added a FAQ --- Unofficial-FAQ.md | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/Unofficial-FAQ.md b/Unofficial-FAQ.md index 4488c25..6244003 100644 --- a/Unofficial-FAQ.md +++ b/Unofficial-FAQ.md @@ -60,4 +60,26 @@ typedef int assert_numbits[sizeof(NI) == sizeof(void*) && NIM_INTBITS == sizeof Then you are likely trying to compile the C sources with a 64bit version of GCC. If you are trying to do this then you should note that there is a ``build64.bat`` file which you should execute instead of the ``build.bat`` file. -If the error does not resemble the above then the problem is likely with the C sources. Ask for help on IRC or submit an issue on github! \ No newline at end of file +If the error does not resemble the above then the problem is likely with the C sources. Ask for help on IRC or submit an issue on github! + +## Is Nim unsafe? + +Usually this comes from Nim's ability to dereference null pointers and it's deal with compiling to C IR. Nim strives to generate C IR that won't cause undefined behavior as easy as how it can be caused by hand written C code. But when there is hand-written Nim code that contains errors like dereferencing a null pointer, there are ways to avoid this: + +- `not nil` Annotation: + - You can use this annotation on any nilable type in your code and the compiler statically checks at compile time that your code can't possibly have a null pointer for that var +- Compiler flags: + - you can pass flags like `-fsanitze`, or `-fsanitize=null` for nil checks, which provide minimal overhead. + - In the near future, `-nilChecks:On|Off` will be available for explicit nil checking and instead of Segmentation Faults, when a null pointer is dereferenced, it will be a NilError Exception + - Also in the near future, `-d:safety` will be available to use along with `-d:release` for performance _and_ safety (see: [#2809](https://github.com/Araq/Nim/issues/2809)) +- `-d:release` config + - by default, `-d:release` turns safety checks off, but if you configure `config/nim.cfg`, you can allow the checks you want enabled when invoking `-d:release` +- Thread Safety + - shared memory via lockable heaps is a feature Nim seems will implement soon. + +You should also keep in mind these 5 points: + 1. It's not a problem in practice in the real world, where people have access to a very good debug mode that catches all sorts of things at compile-time and at run-time. + 2. It's not a problem with the right C compiler configurations. + 3. It's not hard to "fix" this issue anyway. Where "fixing" means "pretending Nim created Ansi C code in the first place" (which it doesn't). + 4. It's furthermore entirely deterministic in debug mode. It's nothing like a data race which you can never effectively test against. + 5. Nim already encourages you to give the type a name and then 'not nil' can be part of the type definition easily \ No newline at end of file