fix #10958: buggy handling of embedded NUL chars

[stevengj]

This fixes the length("\0w") bug brought up in #10958 and a couple of related bugs. (cc @ScottPJones, @jiahao).

Strings with embedded NUL chars are still silently truncated when passed to external C routines in many places (e.g. all of the libuv filesystem routines). My plan is to submit a separate PR defining new Cstring and Cwstring types to use in ccall (instead of Ptr{UInt8} and Ptr{Cwchar_t}, respectively) for NUL-terminated strings, which throw an exception on convert for strings with embedded NULs.

[stevengj]

(I'm working on my Cstring PR now, and am finding a lot of other bugs of this sort, e.g. tryparse(Float64, "234.5\0abcd") silently truncates the string and succeeds.)

[JeffBezanson]

I'd be very worried about the performance of doing an extra pass over every string to check for nuls (e.g. #10428). At least for number parsing this will probably need to be special-cased.

[StefanKarpinski]

The proposal is not to check every string for NULs, just the ones that we pass to C functions that expect NUL-terminated strings. There should, of course, be a way to circumvent that check and just produce a Cstring directly. I really don't think that most C APIs that accept NUL-terminated strings are used for large amounts of data.

[stevengj]

Rather than checking for NULs in some cases, for C routines that we wrote ourselves I am just adding an extra size_t len parameter. For example, in tryparse, I'm just calling jl_try_substrtod rather than jl_try_strtod. Or for jl_parse_input_line I simply added a len parameter. Along the way, I'm finding several bugs.

[JeffBezanson]

Sounds good.

[stevengj]

There are also cases where we are passing strings that are known not to contain NUL, e.g. in

function mktemp()
    b = joinpath(tempdir(), "tmpXXXXXX")
    p = ccall(:mkstemp, Int32, (Ptr{UInt8}, ), b) # modifies b                  
    return (b, fdio(p, true))
end

and I am leaving these as-is.

[StefanKarpinski]

Seems fine but seems like a weird place to eek out such a minuscule but of performance.

[tkelman]

backported in b192bf0