Expose the size of a fixed buffer using sizeof

[sweemer]

Currently the size of a fixed buffer cannot be accessed at runtime, which makes it cumbersome to use APIs like Encoding.GetString(byte* bytes, int byteCount) that require the size at runtime.

One workaround is to define a constant for the size and using that both in the fixed buffer declaration and in all other places where the size is needed, but this can be error prone and hard to enforce.

Another workaround is to use source generation, since the size can be accessed at compile-time, but this approach seems like overkill for most simple use cases.

In practice it seems that most people (including myself on occasion) just hardcode the size everywhere.

I would therefore like to propose allowing the sizeof operator to be used to retrieve the size of fixed buffers. The compiler will replace the call to sizeof with a constant value at compile time so that there will be no runtime overhead. This approach should be much easier to enforce with static analysis tools and also much nicer to use than the other alternatives.

using System.Text;

public unsafe struct S
{
    public fixed byte bytes[10];
}

var s = new S();
unsafe
{
    Encoding.ASCII.GetString(s.bytes, sizeof(s.bytes));
}

[huoyaoyuan]

Duplicate of #8784.

Processing address and length of buffer separately is not what's done in C#. Instead, they should be passed together within a Span or Memory.

As of #8784 (comment) , there was already proposal for creating a Span directly from fixed size buffer at https://github.com/dotnet/csharplang/blob/main/proposals/rejected/fixed-sized-buffers.md. You would be able to get the pointer and length separately, which is not recommended for a while. Overloads like Encoding.GetString(ReadOnlySpan<byte>) should be used instead.

The proposal was not active and there's no interest to fixed size buffer any more. It's just a shorthand of inline arrays.

[sweemer]

Right, the code analysis updates must be at a lower severity than warning, sorry for the confusion. I understand that shipping in the warning state is only justifiable for extremely important reasons.

And now that I think about it, DllImportAttribute has not yet been made deprecated or obsolete, so it wasn't a good example. I'll see if I can approach the right teams to discuss tooling for helping users to migrate to inline arrays.

Thanks again for all your comments, I learned a lot through them!

[tannergooding]

And now that I think about it, DllImportAttribute has not yet been made deprecated or obsolete, so it wasn't a good example

Notably DllImportAttribute also can't ever be made deprecated or obsolete as LibraryImport is a source generator that fundamentally uses it under the covers. The difference is that LibraryImport only uses blittable DllImport signatures and so avoids any dependency on the built-in marshalling system, which is legacy and which has a corresponding attribute that can be used to disable it and warn if you try and use it. It then source generates the relevant marshalling directly in C# as part of the partial method the LibraryImport attribute was placed on.

---

In general there are different scopes for analyzers, warnings, and errors in general.

There are compiler warnings/errors that are built into the language.

There are the official .NET analyzers and code fixes that ship with the SDK and are enabled by default, generally pushing users towards using new features where available. These generally only suggest it where it is "safe" and not likely to introduce breaks or other issues, hence why there isn't one for InlineArray. Many are off by default and you need to change the AnalysisMode and/or AnalysisLevel to see the rest: https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/overview?tabs=net-9. They are also configurable by .editorconfig and can be browsed via https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/code-quality-rule-options and https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/code-style-rule-options

Then there are third party analyzers, which anyone can go and write. This would be the best place to have something like a suggestion to use InlineArray instead of fixed sized buffers as it being 3rd party makes it opt-in and allows handling the various nuances that the SDK cannot trivially suggest itself due to the risk and other issues that were mentioned above.

[CyrusNajmabadi]

Thanks again for all your comments, I learned a lot through them!

Any time. Thanks for all your feedback!

[sweemer]

These generally only suggest it where it is "safe" and not likely to introduce breaks or other issues, hence why there isn't one for InlineArray.

@tannergooding Thanks for the good summary of the different options available. I just want to share that I have successfully migrated my app from fixed-size buffers to inline arrays based on the info I've received in this and other discussions, and fortunately I haven't come across any breaks or issues yet. The only thing is that a lot of code changes were required - more than for migrating from DllImport to LibraryImport - so I can understand the reluctance to provide a quick fix or analyzer for such a non-trivial change.

[Ollhax]

The proposal was not active and there's no interest to fixed size buffer any more. It's just a shorthand of inline arrays.

Is there any way to vote for getting fixed size buffers back on the agenda? I use inline arrays extensively and it would be very useful to get a way to express them more cleanly.