Type confusion with jl_genericmemory_to_string

[bbrehm]

julia> function foo()
       v=UInt8[0x41 for i=1:801];
       popfirst!(v)
       vv=reshape(v, (800, 1))
       vvv = reshape(vv, (800,))
       s = String(vvv)
       Ref(s)
       end
foo (generic function with 1 method)

julia> foo()
Base.RefValue{String}(UInt8[0x41, 0x41, 0x41, 0x41, 0x41, 0x41, 0x41, 0x41, 0x41, 0x41  …  0x41, 0x41, 0x00, 0x41, 0x41, 0x41, 0x41, 0x41, 0x41, 0x41])

From discourse https://discourse.julialang.org/t/does-julia-have-efficient-move-semantics/122165/33

I think the issue is that jl_genericmemory_to_string labors under the mistaken assumption that only a string can be the owner of the memory if how == 3.

As a further issue, I am quite unhappy with jl_genericmemory_to_string mutating the Memory's length field: Memory is supposed to have constant length. If another array, especially a non-Vector, uses the same memory, then it's not supposed to have its size changed under it!

And mutating the memory doesn't really help, there could be other jl_genericmemory_slice to the same memory.

[jakobnissen]

Is there are any good reason the Memory is truncated? After #54457 , can't we just have String(::Vector{UInt8}) change the vector's memory instead of mutating the memory itself?

That being said, a bunch of stuff relies on String(::Vector{UInt8}) being zero-copy. So if you keep another reference to the vector's length, and then change the memory into a string, which you can now mutate through your reference but the compiler believes is immutable, it's a recipe for bugs anyway.