State of destination buffer when ISpanFormattable.TryFormat returns false?

[mawosoft]

I'm hoping for some guidance or "best practice" on how to implement ISpanFormattable.TryFormat, particularly when the destination buffer is too small. This is signaled by returning false, and charsWritten is set to 0.

From the latter, one could assume that the buffer remains unchanged in such a case. However, that's not guaranteed to be true.

I looked at the various implementations in the runtime. A lot of them go to great lengths to determine the required size beforehand and only write to the destination buffer if it is big enough. Others, particularly when using ValueListBuilder internally, start writing to the destination buffer and later realize that the result won't fit.

These differences may have historical reasons, the attitude may have changed over time, or it may be merely a question of how costly the extra step of pre-calculating the required size is.

Some clarification and currently recommended best practice on this matter would be appreciated.

[bartonjs]

I believe our current stance for a Span-based TryWrite is "any part of the buffer between written and Length should be assumed to be garbage on the part of a caller". So if you pass in a 100-item span, and it says it wrote 5, [5] isn't guaranteed unchanged, it might have been used for an intermediate calculation.

If TryWrite returns false it's supposed to out written as 0, in which case the whole of the destination buffer should be assumed garbage.

[EgorBo]

So if you pass in a 100-item span, and it says it wrote 5, [5] isn't guaranteed unchanged

That does not sound right to me if the function returns written = 5 (can only be done when the function returns true) and we wrote/changed more than needed.

For the author's question - if buffer is too small - it's undefined behavior of what we wrote to it while returning false for it, we already have a few examples in BCL when we might do this.

[stephentoub]

and we wrote/changed more than needed.

We could have as part of the process, we're just only guaranteeing the contents up through 5 is valid. That said, I can't think of any situation off the top of my head where we do that.

Basically, the supplied buffer is considered scratch, and we're free to write to any or all of it. Upon returning true, we tell you what portion is considered usable via the written integer out argument, and if we return false, by convention we set that to 0 to indicate nothing is usable.

[mawosoft]

Thanks for the responses.

So those implementations in the runtime that go out of their way to determine if the destination buffer is suitable before writing to it can be chalked up to... different times? individual code style?

[bartonjs]

Both "different times" and "style" apply; there may also be domain concerns... like in cryptography it's generally considered a bad idea to leak out partial answers.

If you see something doing a quick check, those should be fine; if it's an unnaturally complex check then it may just be out of date and might appreciate an issue asking if that extra work should be removed.

[stephentoub]

@mawosoft, can you give specific examples?

[mawosoft]

Sadly, I didn't take any notes. I'll have to look again for specifics.