Span<T>.CopyTo(Span<T>, int index)

[samuel-lucas6]

It seems there's no easy way of copying to a span at a certain index, which would be useful for concatenation (e.g. of bytes). Instead, you're forced to do something like this:

public static Span<byte> Concat(ReadOnlySpan<byte> a, ReadOnlySpan<byte> b)
{
    var array = new byte[a.Length + b.Length];
    a.CopyTo(array);
    b.CopyTo(array.AsSpan(a.Length));
    return array.AsSpan();
}

Instead of something like this:

Span<byte> buffer = stackalloc byte[32];
a.CopyTo(buffer, index: 0);
b.CopyTo(buffer, index: a.Length);

Array.CopyTo(Array array, int index) exists, so it's not clear to me why Span<T>.CopyTo(Span<T>, int index) doesn't exist.

[c-ohle]

@samuel-lucas6
Hi, this works based on one of endless bugs, illogics, wrong security concepts etc regarding spans. This also works in the latest preview versions of .NET 7.0. I've given up writing bug reports.
It's actually an option to quickly get a memory block on a forbidden region on the stack. You must be extremely careful. For example, when debugging, the debug visualizer overwrites this block of memory and the result is corrupt. A Debug.WriteLine works though and to check the result.
But it's not a problem if you know what you're doing. Then it's a ticket to high performance programming.

    unsafe static Span<byte> Concat(ReadOnlySpan<byte> a, ReadOnlySpan<byte> b)
    {
      var p = stackalloc byte[a.Length + b.Length];
      var s = new Span<byte>(p, a.Length + b.Length);
      a.CopyTo(s); b.CopyTo(s.Slice(a.Length));
      return s;
    }

[DaZombieKiller]

The code you posted is completely unsafe and will not produce correct behaviour regardless of how it is used, that is why I downvoted your comment. You may have found a few situations where there are no immediately apparent bugs, but then you are essentially relying on undefined behaviour. You're returning a reference to stack memory that is invalid as soon as the method returns. That memory will get reused for subsequent function calls, which will corrupt the data you have in the Span<T>.

Even if it was safe to return that stackalloc'd memory (it's not), there is also no guarantee that there is enough space on the stack to fit a.Length + b.Length elements. Your code will cause a stack overflow if they are too large (and there are no checks in the method to prevent this from happening). The code is also performing a stackalloc with a non-constant length, which will produce less efficient code than a stackalloc of constant length + slicing.

A safer approach to this API would be the following:

static Span<byte> Concat(ReadOnlySpan<byte> a, ReadOnlySpan<byte> b, Span<byte> scratch)
{
    int length = a.Length + b.Length;
    var buffer = scratch.Length <= length ? scratch[..length] : new byte[length];
    a.CopyTo(buffer);
    b.CopyTo(buffer[a.Length..]);
    return buffer;
}

Which you would use like this:

span = Concat(a, b, stackalloc byte[256]);

[c-ohle]

@DaZombieKiller thanks, yes, your function Concat is correct and safe - a possibility.

My first function Concat was actually showing security problems and bugs in the system regarding Span, mixed with frustration after some bug reports - the stupid reactions - and black humor.

But it's generally about using unused stack-space as described last. For time critical special cases, to avoid allocs, lot of code to manage this or alternative use the slow shared buffer API... there is no better alternative. One time stackalloc per thread, [SkipLocalsInit] of course, and you have a safe base pointer for Span's, for temporary buffers as needed and nothing is faster, one stackalloc - no memory managmend - and if you know what you are doing than it is safe.

[tannergooding]

Even when you know what you're doing, a long term or large stack allocation is extremely dangerous and potentially problematic.

It may be "fast", but it also puts you at an increased risk of stack overflow and other issues.

For large or long lived allocations, relying on the GC or NativeMemory.Alloc is almost always a better choice. If it is a 1-time long-lived allocation, then the "overhead" of the allocation is also negligible.

-- "large" here is defined as anything over 1KB. You should practically never allocate more than 1KB of stack space for a given method frame (and this is indeed the cutoff for alloca in native).

[c-ohle]

@tannergooding hello, this time it was not an API proposal :-)
I said not for long term - for temp buffers within function runtime.
stack overflow, not possible, such stackalloc is necessary only one time per thread and environment check can be done long before.
alloca... different case (for stackalloc), there is no real allocation behind, it is on VirtualMemory, only the address space is reserved, physical allocation happens on block access.

[c-ohle]

@tannergooding There is much progress regarding BigRational, found new solutions
that makes builder solutions obsolat, for BigInteger too, safe API following the framework design guidelines, works close together with INumber, got support from other devs, all up to date now of the NET7 dev master-branch.
It would be nice if you could find some time next week to check.

[huoyaoyuan]

You can just do span1.CopyTo(span2.Slice(index)) or span1.CopyTo[span2[index..]]. No more overload is needed.

[samuel-lucas6]

Thank you; I will use this approach. However, it's less readable than Span<T>.CopyTo(Span<T>, int index) would be when you want to concatenate multiple spans. It seems like something that should exist for that reason and for consistency with Array.CopyTo().

[huoyaoyuan]

Array-accepting methods and span-accepting methods are consistent themselves. For example in stream methods, all array-accepting methods have index and length parameters, while span-accepting methods don't have them.

[samuel-lucas6]

Fair point. I've only just started using spans. I still think it's a shame this doesn't exist.