[API Proposal]: `Convert.ToInt32` overload that takes a `ROS<char>` instead of a `string`

[carlossanlop]

Background and motivation

I'm working on some code that contains fields that represent numbers in octal base, saved as ASCII characters.

To convert them to a ten base number, I need to do the following:

byte[] buffer = new[]{ 0x30, 0x30, 0x30, 0x30, 0x36, 0x34, 0x34, 0x0 }; // 0000644\0
string str = Encoding.ASCII.GetString(buffer.AsSpan()); // "000644"
int tenBaseNumber = Convert.ToInt32(str, fromBase: 8); // 420

The third line is inefficient. Ideally, I should be able to pass a the string as a ReadOnlySpan<char>.

This can be a problem in my use case, because when I open a tar archive, I need to iterate through all the tar entries, and each entry header has multiple octal fields like the one above.

API Proposal

namespace System
{
 public static class Convert
 {
 public static int ToInt32(ReadOnlySpan<char> value, int fromBase);
 }
}

API Usage

int tenBaseNumber = Convert.ToInt32(str.AsSpan(), fromBase: 8); // 420

If this gets approved, I can work on adding this API.

cc @GrabYourPitchforks

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

I'm working on reading a tar file header, which contains fields that represent numbers in octal base, saved as ASCII characters.

To convert them to a ten base number, I need to do the following:

byte[] buffer = new[]{ 0x30, 0x30, 0x30, 0x30, 0x36, 0x34, 0x34, 0x0 }; // 0000644\0
string str = Encoding.ASCII.GetString(buffer.AsSpan()); // "000644"
int tenBaseNumber = Convert.ToInt32(str, fromBase: 8); // 420

The third line is inefficient. Ideally, I should be able to pass a the string as a ReadOnlySpan<char>.

This can be a problem in my use case, because when I open a tar archive, I need to iterate through all the tar entries, and each entry header has multiple octal fields like the one above.

API Proposal

namespace System
{
 public static class Convert
 {
 public static int ToInt32(ReadOnlySpan<char> value, int fromBase);
 }
}

API Usage

int tenBaseNumber = Convert.ToInt32(str.AsSpan(), fromBase: 8); // 420

If this gets approved, I can work on adding this API.

cc @GrabYourPitchforks

Author:	carlossanlop
Assignees:	-
Labels:	api-suggestion, area-System.Runtime, untriaged
Milestone:	-

[danmoseley]

Question is whether this would have broad utility vs. just having your own helper method.

[jkotas]

The third line is inefficient. Ideally, I should be able to pass a the string as a ReadOnlySpan

The second line is inefficient too. Ideally, you would parse the number directly from ReadOnlySpan<byte>.

[davidfowl]

Don't we already have Utf8Parser.TryParse for this scenario?

[stephentoub]

Don't we already have Utf8Parser.TryParse for this scenario?

Carlos wants to read octal.

[davidfowl]

I was just looking to see if we supported bases on those APIs and it turns out we don't.

[stephentoub]

Yeah. I'd be inclined to say that if we want to support bases, these should be overloads on Utf8Parser, and if we want something similar for chars, on int and friends. Convert has some unusual legacy behaviors around parsing.

[tannergooding]

Yeah. I'd be inclined to say that if we want to support bases, these should be overloads on Utf8Parser, and if we want something similar for chars, on int and friends

If we were doing that, I imagine the natural extension from what we have today is:

1. A new System.Globalization.NumberStyles.OctalNumber enum member (matching HexNumber) for parsing
2. Some new "well known" format specifier (like x, X matching hexadecimal) for formatting

I'd think, at most, this would extend to 2, 8, 10, and 16 (where we already expose 10 and 16). I'm not convinced we really need support for other "arbitrary" bases as they become increasingly more specialized.

Given what we have/use today. b/B for binary and o/O for octal should be "free" format specifiers and OctalNumber/BinaryNumber are fairly well understood.
C# already supports 0b for binary and octal is typically either 0###, o#### or 0o####, the last of which is a "semi-natural" extension from what we allow for the others.

[GrabYourPitchforks]

IMO there is still utility to the proposed method. If you have a string like a row in a CSV, having spanified overloads on Convert would obviate calling Substring over and over again. This falls under the umbrella of what I consider general spanification goodness for parsing routines.

[carlossanlop]

Question is whether this would have broad utility vs. just having your own helper method.

@danmoseley I don't have an easy way to create a helper method that avoids passing the string. The main reason why I need to convert the byte array to a string is because the characters in the byte array could be in any encoding, not just ASCII.

Note: my specific use case is for ASCII so far. There are some string fields in my code that are UTF8, but their numbers are encoded in decimal base, not octal.

---

The second line is inefficient too. Ideally, you would parse the number directly from ReadOnlySpan<byte>.

@jkotas so you would prefer a method that automatically detects the encoding of the chars saved in the byte array?

public static int ToInt32(ReadOnlySpan<byte> value, int fromBase);

Should the user indicate the encoding manually?

public static int ToInt32(ReadOnlySpan<byte> value, int fromBase, Encoding encoding);

---

I'd be inclined to say that if we want to support bases, these should be overloads on Utf8Parser, and if we want something similar for chars, on int and friends. Convert has some unusual legacy behaviors around parsing.

@stephentoub but what if the string is in an encoding that is not Utf8? Do we have parsers for other encodings? It feels like Convert would be a better place because it would be encoding-agnostic.

---

@tannergooding It would be great to add more support to octal numbers. They are often used in the Unix world. For example, the Mode attribute is saved in octal (644, 755, etc.).

---

@GrabYourPitchforks I noticed the BitConverter class has similar methods that take a byte array. Would that class be a better location than Convert? I am not very familiar with the specific differences of the two classes, I was hoping you could enlighten me.

We need to be careful to detect the encoding of the characters stored in the byte array. Is it better to automatically detect the encoding of the chars in the byte array, or should the user manually specify the encoding?

namespace System
{
 // What if we add them to BitConverter?
 public static class BitConverter
 {
 public static int ToInt32(byte[] value, int startIndex); // Exists
 public static int ToInt32(ReadOnlySpan<byte> value); // Exists
 
 public static int ToInt32(ReadOnlySpan<byte> value, int fromBase); // Should autodetect encoding?
 public static int ToInt32(ReadOnlySpan<byte> value, int fromBase, Encoding encoding); // Should the user manually specify encoding?
 }
}

---

I suspect implementing the ROS overload would be relatively simple because we already have it in the form of an internal helper method:

runtime/src/libraries/System.Private.CoreLib/src/System/Convert.cs

Lines 2214 to 2223 in b07b26d

	public static int ToInt32(string? value, int fromBase)
	{
	if (fromBase != 2 && fromBase != 8 && fromBase != 10 && fromBase != 16)
	{
	throw new ArgumentException(SR.Arg_InvalidBase);
	}
	return value != null ?
	ParseNumbers.StringToInt(value.AsSpan(), fromBase, ParseNumbers.IsTight) :
	0;
	}

[jkotas]

@jkotas so you would prefer a method that automatically detects the encoding of the chars saved in the byte array?

You cannot really detect the encoding of the chars. It has to be specified by the caller in one way or the other.

Personally, I think this it too niche need to add methods for in the core library. It is trivial to open code a method tailored for the specific case as needed.