Your WORST solution is what the C backend would have emitted.
I don't think adding a nil check will become the performance bottleneck. Here
is my test code:
import times
proc MulDiv*(P1: int32, P2: int32, P3: int32): int32 {.stdcall,
discardable, dynlib: "kernel32", importc.}
proc test(s: cstring) =
# do someting, to ma
The problem is that a `nil` check can always be inserted manually, but it's
harder to get rid of it when the compiler emits it. Conversions to `cstring`
should be as fast as possible and code size should be small.
**@yglukhov** I have to say, that I do agree with your pull request. a nil
string should be NULL when converted to a cstring. I think the problem here is,
that values of type string can be of no string at all (nil), and functions can
be implemented that nil is a totally valid argument. I think f
Related discussion:
[https://github.com/nim-lang/Nim/pull/3261](https://github.com/nim-lang/Nim/pull/3261)
As far as I know, cstring is just a pointer to the char's array. The inner
representation of the string type contains such kind of array, so the converter
just passed the array pointer from the inner representation without any
nil-checks to your test procedure.
Probably the converter should per
proc test(x: cstring) = echo cast[int](x)
var str: string = nil
test(nil) # output 0 -> correct
test(str) # output 8 ??
I think this should be a bug.
I use "Nim Compiler Version 0.15.2 (2016-10-23) [Windows: i386]"
