-
Notifications
You must be signed in to change notification settings - Fork 4.9k
FromBase64Transform.InputBlockSize set to 4 instead of 1 #39599
FromBase64Transform.InputBlockSize set to 4 instead of 1 #39599
Conversation
public int OutputBlockSize => 3; | ||
public bool CanTransformMultipleBlocks => false; | ||
public bool CanTransformMultipleBlocks => true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
though that means it'll almost never use the stackalloc buffers
(from https://github.com/dotnet/corefx/issues/39583#issuecomment-512854180)
Are there any statistics about the typical inputCount
(i.e. stream length on which CryptoStream should operate)? With these numbers the buffers could be tweaked (stackalloc / renting).
If not, I believe the current implementation of stackalloc / renting is still good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there any statistics about the typical inputCount (i.e. stream length on which CryptoStream should operate)?
Nope.
The numbers I do have: apisof.net reports 1% APIPort usage for FromBase64Transform, and 0.4% for ToBase64Transform (25% CryptoStream)... and RC2 has almost more usage than that (somehow). Convert.ToBase64String(byte[]) has 51.4% usage, and Convert.FromBase64String is 43,8% usage.
So "no idea what the inputs into this are, but it's definitely not the common way of doing Base64".
public int OutputBlockSize => 3; | ||
public bool CanTransformMultipleBlocks => false; | ||
public bool CanTransformMultipleBlocks => true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to see at least some test have to change as a result of this. Can you add a test that just checks that the block sizes and can-transform match what we want them to be? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests are added with 886b05b
{ | ||
using (var transform = new ToBase64Transform()) | ||
{ | ||
Assert.False(transform.CanTransformMultipleBlocks); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is ToBase64Transform already effectively implemented as "true" here? (TransformBlock accepting an integer multiple of the input block size, TransformFinalBlock accepting any arbitrary amount of data) Or would flipping it to true actually cause failures?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is ToBase64Transform already effectively implemented as "true" here?
No it's not. It just transforms one block at a time.
Lines 37 to 39 in 886b05b
// For now, only convert 3 bytes to 4 | |
Span<byte> input = inputBuffer.AsSpan(inputOffset, InputBlockSize); | |
Span<byte> output = outputBuffer.AsSpan(outputOffset, OutputBlockSize); |
Lines 65 to 71 in 886b05b
else if (inputCount > InputBlockSize) | |
{ | |
ThrowHelper.ThrowArgumentOutOfRange(ThrowHelper.ExceptionArgument.inputCount); | |
} | |
// Again, for now only a block at a time | |
Span<byte> input = inputBuffer.AsSpan(inputOffset, inputCount); |
See also https://github.com/dotnet/corefx/issues/39583#issuecomment-513304310 for this.
Or would flipping it to true actually cause failures?
This test
public static void ValidateToBase64CryptoStream(string data, string encoding) |
yield return new object[] { "foobar", "Zm9vYmFy" }; |
Retriggering CI to see if Windows x86_Release still fails |
Triggering again to hopefully get a clean run. |
Fixes https://github.com/dotnet/corefx/issues/39583 and sets
FromBase64Transform.CanTransformMultipleBlocks = true
(cf. https://github.com/dotnet/corefx/issues/39583#issuecomment-512854180).