Remove the unsafe code from Kestrel

[davidfowl]

This is more of an aspirational goal instead of something we would immediately do but we should have enough primitives in the BCL now that this is viable. Of course there might be a tiny performance hit but it might be worth it if we can remove all of the unsafe code.

cc @DamianEdwards @blowdart @halter73 @KrzysztofCwalina @benaadams

[benaadams]

Be nice to do it and not get a performance hit. For example if the Jit could recognise slice advancing and propagate bounds checking; as well as elide slice bounds checking and secondary span creation so that; in the correct pattern, it could be as near cost to a pointer bump

[blowdart]

@benaadams don't take this away from me

[KrzysztofCwalina]

@davidfowl, do you consider the http parser to be "kestrel"? If yes, do you think we can remove unsafe code from the parser?

[davidfowl]

@KrzysztofCwalina yes and yes. I had a branch here in the 2.0 time frame before JIT optimizations on span and the performance hit was too big https://github.com/aspnet/KestrelHttpServer/tree/davidfowl/ideal-parser. I need to go back to it now that those things were addressed.

[davidfowl]

This is a long running issue. We should be able to track this somehow.

[davidfowl]

Actually, it would be great if we could quantify this and drive it down.

[BrennanConroy]

List all currently known methods as a checklist?

[davidfowl]

Yep

[GrabYourPitchforks]

Folks working on this may be interested in the conversation taking place at dotnet/runtime#41418. That issue attempts to catalog the various MemoryMarshal and related APIs as safe vs. unsafe-equivalent.

tl;dr: if you're removing use of unsafe in the spirit of reliability or security hardening, avoid the unsafe-equivalent APIs listed in the table in that issue, otherwise your work likely won't result in any measurable hardening.