Fix bool.TryParse/Format on big-endian systems

[uweigand]

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

[ghost]

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

[EgorBo]

I don't understand, wasn't .WriteUInt64LittleEndian supposed to handle endianess via ReverseEndianness() for value?

/// <summary>/// Write a UInt64 into a span of bytes as little endian./// </summary>[CLSCompliant(false)][MethodImpl(MethodImplOptions.AggressiveInlining)]publicstaticvoidWriteUInt64LittleEndian(Span<byte>destination,ulongvalue){if(!BitConverter.IsLittleEndian){value=ReverseEndianness(value);}MemoryMarshal.Write(destination,refvalue);}

[EgorBo]

if it wasn't then you can re-write code to just MemoryMarshal.Write(destination, 0x73006C00610046); I guess

[uweigand]

The problem is that you need to distinguish between swapping the order of the characters and the order of the bytes within one two-byte character. See #64782 (comment) for an example. There's no single store that does the correct thing for both of these simultaneously on both big- and little-endian platforms.

[EgorBo]

I see, thanks for explanation! anyway maybe it's still better to use

MemoryMarshal.Write(destination, IsLittleEndian ? 0x73006C00610046 : ...)

?
less verbose IMO

[uweigand]

That would work as well. I can try this out if you prefer.

[uweigand]

Patch updated accordingly.

[ghost]

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

Issue Details

---

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

Author:	uweigand
Assignees:	-
Labels:	area-System.Runtime, community-contribution
Milestone:	-

[stephentoub]

Thanks for fixing.

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

[uweigand]

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

Do you mean these tests (part of libs.tests):

 System.Text.RegularExpressions.Generators.Tests Total: 164, Errors: 0, Failed: 0, Skipped: 0, Time: 6.729s
System.Text.RegularExpressions.Tests Total: 14829, Errors: 0, Failed: 0, Skipped: 0, Time: 59.637s

Those seem to be all good now ...

[stephentoub]

Those seem to be all good now ...

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

Can you try compiling this program using a .NET 7 SDK on a little-endian machine:

usingSystem.Text.RegularExpressions;partialclassProgram{publicstaticvoidMain()=>Console.WriteLine(Example().IsMatch(@"1abcd"));[RegexGenerator(@"\dabcd")]publicstaticpartialRegexExample();}

and then running the resulting program on the big-endian one? It should print true, but I'm betting it's going to print false.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

[uweigand]

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

I see.

It should print true, but I'm betting it's going to print false.

Yes, this is indeed what happens.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

[stephentoub]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

[uweigand]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

I repeated the test above using today's snapshot (dotnet-sdk-7.0.100-preview.2.22118.2-linux-x64.tar.gz) to build the regex test case on Intel, and can confirm that the resulting assembly now outputs "True" when run on s390x.

Thanks!

[stephentoub]

Thanks for confirming, @uweigand.

[uweigand]

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

[ghost]

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

[EgorBo]

I don't understand, wasn't .WriteUInt64LittleEndian supposed to handle endianess via ReverseEndianness() for value?

/// <summary>/// Write a UInt64 into a span of bytes as little endian./// </summary>[CLSCompliant(false)][MethodImpl(MethodImplOptions.AggressiveInlining)]publicstaticvoidWriteUInt64LittleEndian(Span<byte>destination,ulongvalue){if(!BitConverter.IsLittleEndian){value=ReverseEndianness(value);}MemoryMarshal.Write(destination,refvalue);}

[EgorBo]

if it wasn't then you can re-write code to just MemoryMarshal.Write(destination, 0x73006C00610046); I guess

[uweigand]

The problem is that you need to distinguish between swapping the order of the characters and the order of the bytes within one two-byte character. See #64782 (comment) for an example. There's no single store that does the correct thing for both of these simultaneously on both big- and little-endian platforms.

[EgorBo]

I see, thanks for explanation! anyway maybe it's still better to use

MemoryMarshal.Write(destination, IsLittleEndian ? 0x73006C00610046 : ...)

?
less verbose IMO

[uweigand]

That would work as well. I can try this out if you prefer.

[uweigand]

Patch updated accordingly.

[ghost]

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

Issue Details

---

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

Author:	uweigand
Assignees:	-
Labels:	area-System.Runtime, community-contribution
Milestone:	-

[stephentoub]

Thanks for fixing.

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

[uweigand]

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

Do you mean these tests (part of libs.tests):

 System.Text.RegularExpressions.Generators.Tests Total: 164, Errors: 0, Failed: 0, Skipped: 0, Time: 6.729s
System.Text.RegularExpressions.Tests Total: 14829, Errors: 0, Failed: 0, Skipped: 0, Time: 59.637s

Those seem to be all good now ...

[stephentoub]

Those seem to be all good now ...

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

Can you try compiling this program using a .NET 7 SDK on a little-endian machine:

usingSystem.Text.RegularExpressions;partialclassProgram{publicstaticvoidMain()=>Console.WriteLine(Example().IsMatch(@"1abcd"));[RegexGenerator(@"\dabcd")]publicstaticpartialRegexExample();}

and then running the resulting program on the big-endian one? It should print true, but I'm betting it's going to print false.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

[uweigand]

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

I see.

It should print true, but I'm betting it's going to print false.

Yes, this is indeed what happens.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

[stephentoub]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

[uweigand]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

I repeated the test above using today's snapshot (dotnet-sdk-7.0.100-preview.2.22118.2-linux-x64.tar.gz) to build the regex test case on Intel, and can confirm that the resulting assembly now outputs "True" when run on s390x.

Thanks!

[stephentoub]

Thanks for confirming, @uweigand.

[uweigand]

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

[ghost]

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

[EgorBo]

I don't understand, wasn't .WriteUInt64LittleEndian supposed to handle endianess via ReverseEndianness() for value?

/// <summary>/// Write a UInt64 into a span of bytes as little endian./// </summary>[CLSCompliant(false)][MethodImpl(MethodImplOptions.AggressiveInlining)]publicstaticvoidWriteUInt64LittleEndian(Span<byte>destination,ulongvalue){if(!BitConverter.IsLittleEndian){value=ReverseEndianness(value);}MemoryMarshal.Write(destination,refvalue);}

[EgorBo]

if it wasn't then you can re-write code to just MemoryMarshal.Write(destination, 0x73006C00610046); I guess

[uweigand]

The problem is that you need to distinguish between swapping the order of the characters and the order of the bytes within one two-byte character. See #64782 (comment) for an example. There's no single store that does the correct thing for both of these simultaneously on both big- and little-endian platforms.

[EgorBo]

I see, thanks for explanation! anyway maybe it's still better to use

MemoryMarshal.Write(destination, IsLittleEndian ? 0x73006C00610046 : ...)

?
less verbose IMO

[uweigand]

That would work as well. I can try this out if you prefer.

[uweigand]

Patch updated accordingly.

[ghost]

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

Issue Details

---

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

Author:	uweigand
Assignees:	-
Labels:	area-System.Runtime, community-contribution
Milestone:	-

[stephentoub]

Thanks for fixing.

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

[uweigand]

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

Do you mean these tests (part of libs.tests):

 System.Text.RegularExpressions.Generators.Tests Total: 164, Errors: 0, Failed: 0, Skipped: 0, Time: 6.729s
System.Text.RegularExpressions.Tests Total: 14829, Errors: 0, Failed: 0, Skipped: 0, Time: 59.637s

Those seem to be all good now ...

[stephentoub]

Those seem to be all good now ...

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

Can you try compiling this program using a .NET 7 SDK on a little-endian machine:

usingSystem.Text.RegularExpressions;partialclassProgram{publicstaticvoidMain()=>Console.WriteLine(Example().IsMatch(@"1abcd"));[RegexGenerator(@"\dabcd")]publicstaticpartialRegexExample();}

and then running the resulting program on the big-endian one? It should print true, but I'm betting it's going to print false.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

[uweigand]

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

I see.

It should print true, but I'm betting it's going to print false.

Yes, this is indeed what happens.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

[stephentoub]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

[uweigand]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

I repeated the test above using today's snapshot (dotnet-sdk-7.0.100-preview.2.22118.2-linux-x64.tar.gz) to build the regex test case on Intel, and can confirm that the resulting assembly now outputs "True" when run on s390x.

Thanks!

[stephentoub]

Thanks for confirming, @uweigand.

[uweigand]

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

[ghost]

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

[EgorBo]

I don't understand, wasn't .WriteUInt64LittleEndian supposed to handle endianess via ReverseEndianness() for value?

/// <summary>/// Write a UInt64 into a span of bytes as little endian./// </summary>[CLSCompliant(false)][MethodImpl(MethodImplOptions.AggressiveInlining)]publicstaticvoidWriteUInt64LittleEndian(Span<byte>destination,ulongvalue){if(!BitConverter.IsLittleEndian){value=ReverseEndianness(value);}MemoryMarshal.Write(destination,refvalue);}

[EgorBo]

if it wasn't then you can re-write code to just MemoryMarshal.Write(destination, 0x73006C00610046); I guess

[uweigand]

The problem is that you need to distinguish between swapping the order of the characters and the order of the bytes within one two-byte character. See #64782 (comment) for an example. There's no single store that does the correct thing for both of these simultaneously on both big- and little-endian platforms.

[EgorBo]

I see, thanks for explanation! anyway maybe it's still better to use

MemoryMarshal.Write(destination, IsLittleEndian ? 0x73006C00610046 : ...)

?
less verbose IMO

[uweigand]

That would work as well. I can try this out if you prefer.

[uweigand]

Patch updated accordingly.

[ghost]

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

Issue Details

---

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

Author:	uweigand
Assignees:	-
Labels:	area-System.Runtime, community-contribution
Milestone:	-

[stephentoub]

Thanks for fixing.

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

[uweigand]

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

Do you mean these tests (part of libs.tests):

 System.Text.RegularExpressions.Generators.Tests Total: 164, Errors: 0, Failed: 0, Skipped: 0, Time: 6.729s
System.Text.RegularExpressions.Tests Total: 14829, Errors: 0, Failed: 0, Skipped: 0, Time: 59.637s

Those seem to be all good now ...

[stephentoub]

Those seem to be all good now ...

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

Can you try compiling this program using a .NET 7 SDK on a little-endian machine:

usingSystem.Text.RegularExpressions;partialclassProgram{publicstaticvoidMain()=>Console.WriteLine(Example().IsMatch(@"1abcd"));[RegexGenerator(@"\dabcd")]publicstaticpartialRegexExample();}

and then running the resulting program on the big-endian one? It should print true, but I'm betting it's going to print false.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

[uweigand]

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

I see.

It should print true, but I'm betting it's going to print false.

Yes, this is indeed what happens.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

[stephentoub]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

[uweigand]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

I repeated the test above using today's snapshot (dotnet-sdk-7.0.100-preview.2.22118.2-linux-x64.tar.gz) to build the regex test case on Intel, and can confirm that the resulting assembly now outputs "True" when run on s390x.

Thanks!

[stephentoub]

Thanks for confirming, @uweigand.

[uweigand]

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

[ghost]

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

[EgorBo]

I don't understand, wasn't .WriteUInt64LittleEndian supposed to handle endianess via ReverseEndianness() for value?

/// <summary>/// Write a UInt64 into a span of bytes as little endian./// </summary>[CLSCompliant(false)][MethodImpl(MethodImplOptions.AggressiveInlining)]publicstaticvoidWriteUInt64LittleEndian(Span<byte>destination,ulongvalue){if(!BitConverter.IsLittleEndian){value=ReverseEndianness(value);}MemoryMarshal.Write(destination,refvalue);}

[EgorBo]

if it wasn't then you can re-write code to just MemoryMarshal.Write(destination, 0x73006C00610046); I guess

[uweigand]

The problem is that you need to distinguish between swapping the order of the characters and the order of the bytes within one two-byte character. See #64782 (comment) for an example. There's no single store that does the correct thing for both of these simultaneously on both big- and little-endian platforms.

[EgorBo]

I see, thanks for explanation! anyway maybe it's still better to use

MemoryMarshal.Write(destination, IsLittleEndian ? 0x73006C00610046 : ...)

?
less verbose IMO

[uweigand]

That would work as well. I can try this out if you prefer.

[uweigand]

Patch updated accordingly.

[ghost]

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

Issue Details

---

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

Author:	uweigand
Assignees:	-
Labels:	area-System.Runtime, community-contribution
Milestone:	-

[stephentoub]

Thanks for fixing.

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

[uweigand]

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

Do you mean these tests (part of libs.tests):

 System.Text.RegularExpressions.Generators.Tests Total: 164, Errors: 0, Failed: 0, Skipped: 0, Time: 6.729s
System.Text.RegularExpressions.Tests Total: 14829, Errors: 0, Failed: 0, Skipped: 0, Time: 59.637s

Those seem to be all good now ...

[stephentoub]

Those seem to be all good now ...

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

Can you try compiling this program using a .NET 7 SDK on a little-endian machine:

usingSystem.Text.RegularExpressions;partialclassProgram{publicstaticvoidMain()=>Console.WriteLine(Example().IsMatch(@"1abcd"));[RegexGenerator(@"\dabcd")]publicstaticpartialRegexExample();}

and then running the resulting program on the big-endian one? It should print true, but I'm betting it's going to print false.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

[uweigand]

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

I see.

It should print true, but I'm betting it's going to print false.

Yes, this is indeed what happens.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

[stephentoub]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

[uweigand]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

I repeated the test above using today's snapshot (dotnet-sdk-7.0.100-preview.2.22118.2-linux-x64.tar.gz) to build the regex test case on Intel, and can confirm that the resulting assembly now outputs "True" when run on s390x.

Thanks!

[stephentoub]

Thanks for confirming, @uweigand.

[uweigand]

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

[ghost]

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

[EgorBo]

I don't understand, wasn't .WriteUInt64LittleEndian supposed to handle endianess via ReverseEndianness() for value?

/// <summary>/// Write a UInt64 into a span of bytes as little endian./// </summary>[CLSCompliant(false)][MethodImpl(MethodImplOptions.AggressiveInlining)]publicstaticvoidWriteUInt64LittleEndian(Span<byte>destination,ulongvalue){if(!BitConverter.IsLittleEndian){value=ReverseEndianness(value);}MemoryMarshal.Write(destination,refvalue);}

[EgorBo]

if it wasn't then you can re-write code to just MemoryMarshal.Write(destination, 0x73006C00610046); I guess

[uweigand]

The problem is that you need to distinguish between swapping the order of the characters and the order of the bytes within one two-byte character. See #64782 (comment) for an example. There's no single store that does the correct thing for both of these simultaneously on both big- and little-endian platforms.

[EgorBo]

I see, thanks for explanation! anyway maybe it's still better to use

MemoryMarshal.Write(destination, IsLittleEndian ? 0x73006C00610046 : ...)

?
less verbose IMO

[uweigand]

That would work as well. I can try this out if you prefer.

[uweigand]

Patch updated accordingly.

[ghost]

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

Issue Details

---

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

Author:	uweigand
Assignees:	-
Labels:	area-System.Runtime, community-contribution
Milestone:	-

[stephentoub]

Thanks for fixing.

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

[uweigand]

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

Do you mean these tests (part of libs.tests):

 System.Text.RegularExpressions.Generators.Tests Total: 164, Errors: 0, Failed: 0, Skipped: 0, Time: 6.729s
System.Text.RegularExpressions.Tests Total: 14829, Errors: 0, Failed: 0, Skipped: 0, Time: 59.637s

Those seem to be all good now ...

[stephentoub]

Those seem to be all good now ...

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

Can you try compiling this program using a .NET 7 SDK on a little-endian machine:

usingSystem.Text.RegularExpressions;partialclassProgram{publicstaticvoidMain()=>Console.WriteLine(Example().IsMatch(@"1abcd"));[RegexGenerator(@"\dabcd")]publicstaticpartialRegexExample();}

and then running the resulting program on the big-endian one? It should print true, but I'm betting it's going to print false.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

[uweigand]

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

I see.

It should print true, but I'm betting it's going to print false.

Yes, this is indeed what happens.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

[stephentoub]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

[uweigand]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

I repeated the test above using today's snapshot (dotnet-sdk-7.0.100-preview.2.22118.2-linux-x64.tar.gz) to build the regex test case on Intel, and can confirm that the resulting assembly now outputs "True" when run on s390x.

Thanks!

[stephentoub]

Thanks for confirming, @uweigand.

[uweigand]

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

[ghost]

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

[EgorBo]

I don't understand, wasn't .WriteUInt64LittleEndian supposed to handle endianess via ReverseEndianness() for value?

/// <summary>/// Write a UInt64 into a span of bytes as little endian./// </summary>[CLSCompliant(false)][MethodImpl(MethodImplOptions.AggressiveInlining)]publicstaticvoidWriteUInt64LittleEndian(Span<byte>destination,ulongvalue){if(!BitConverter.IsLittleEndian){value=ReverseEndianness(value);}MemoryMarshal.Write(destination,refvalue);}

[EgorBo]

if it wasn't then you can re-write code to just MemoryMarshal.Write(destination, 0x73006C00610046); I guess

[uweigand]

The problem is that you need to distinguish between swapping the order of the characters and the order of the bytes within one two-byte character. See #64782 (comment) for an example. There's no single store that does the correct thing for both of these simultaneously on both big- and little-endian platforms.

[EgorBo]

I see, thanks for explanation! anyway maybe it's still better to use

MemoryMarshal.Write(destination, IsLittleEndian ? 0x73006C00610046 : ...)

?
less verbose IMO

[uweigand]

That would work as well. I can try this out if you prefer.

[uweigand]

Patch updated accordingly.

[ghost]

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

Issue Details

---

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

Author:	uweigand
Assignees:	-
Labels:	area-System.Runtime, community-contribution
Milestone:	-

[stephentoub]

Thanks for fixing.

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

[uweigand]

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

Do you mean these tests (part of libs.tests):

 System.Text.RegularExpressions.Generators.Tests Total: 164, Errors: 0, Failed: 0, Skipped: 0, Time: 6.729s
System.Text.RegularExpressions.Tests Total: 14829, Errors: 0, Failed: 0, Skipped: 0, Time: 59.637s

Those seem to be all good now ...

[stephentoub]

Those seem to be all good now ...

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

Can you try compiling this program using a .NET 7 SDK on a little-endian machine:

usingSystem.Text.RegularExpressions;partialclassProgram{publicstaticvoidMain()=>Console.WriteLine(Example().IsMatch(@"1abcd"));[RegexGenerator(@"\dabcd")]publicstaticpartialRegexExample();}

and then running the resulting program on the big-endian one? It should print true, but I'm betting it's going to print false.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

[uweigand]

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

I see.

It should print true, but I'm betting it's going to print false.

Yes, this is indeed what happens.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

[stephentoub]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

[uweigand]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

I repeated the test above using today's snapshot (dotnet-sdk-7.0.100-preview.2.22118.2-linux-x64.tar.gz) to build the regex test case on Intel, and can confirm that the resulting assembly now outputs "True" when run on s390x.

Thanks!

[stephentoub]

Thanks for confirming, @uweigand.

[uweigand]

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

[ghost]

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

[EgorBo]

I don't understand, wasn't .WriteUInt64LittleEndian supposed to handle endianess via ReverseEndianness() for value?

/// <summary>/// Write a UInt64 into a span of bytes as little endian./// </summary>[CLSCompliant(false)][MethodImpl(MethodImplOptions.AggressiveInlining)]publicstaticvoidWriteUInt64LittleEndian(Span<byte>destination,ulongvalue){if(!BitConverter.IsLittleEndian){value=ReverseEndianness(value);}MemoryMarshal.Write(destination,refvalue);}

[EgorBo]

if it wasn't then you can re-write code to just MemoryMarshal.Write(destination, 0x73006C00610046); I guess

[uweigand]

The problem is that you need to distinguish between swapping the order of the characters and the order of the bytes within one two-byte character. See #64782 (comment) for an example. There's no single store that does the correct thing for both of these simultaneously on both big- and little-endian platforms.

[EgorBo]

I see, thanks for explanation! anyway maybe it's still better to use

MemoryMarshal.Write(destination, IsLittleEndian ? 0x73006C00610046 : ...)

?
less verbose IMO

[uweigand]

That would work as well. I can try this out if you prefer.

[uweigand]

Patch updated accordingly.

[ghost]

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

Issue Details

---

• Fix regression after Streamline bool.TryParse/Format #64782

CC @stephentoub

Author:	uweigand
Assignees:	-
Labels:	area-System.Runtime, community-contribution
Milestone:	-

[stephentoub]

Thanks for fixing.

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

[uweigand]

Are we running the regex tests on the s390x? I would expect it's going to have similar problems.

Do you mean these tests (part of libs.tests):

 System.Text.RegularExpressions.Generators.Tests Total: 164, Errors: 0, Failed: 0, Skipped: 0, Time: 6.729s
System.Text.RegularExpressions.Tests Total: 14829, Errors: 0, Failed: 0, Skipped: 0, Time: 59.637s

Those seem to be all good now ...

[stephentoub]

Those seem to be all good now ...

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

Can you try compiling this program using a .NET 7 SDK on a little-endian machine:

usingSystem.Text.RegularExpressions;partialclassProgram{publicstaticvoidMain()=>Console.WriteLine(Example().IsMatch(@"1abcd"));[RegexGenerator(@"\dabcd")]publicstaticpartialRegexExample();}

and then running the resulting program on the big-endian one? It should print true, but I'm betting it's going to print false.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

[uweigand]

Thanks for looking. I think there's actually still an issue there, but it's masked by limitations in our test infrastructure. .NET 7 includes a source generator for regex, where the generator will emit into the .dll the code for the regex implementation. I expect if you were to take a .dll compiled on a little-endian machine and run it on the s390x, or vice versa, you'd see operations fail.

I see.

It should print true, but I'm betting it's going to print false.

Yes, this is indeed what happens.

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

[stephentoub]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

[uweigand]

I'll prepare a fix for it, but I'm going to need your help in validating its correctness.

Sure, happy to help! Thanks for thinking of this.

I ended up just deleting the offending code instead.

I repeated the test above using today's snapshot (dotnet-sdk-7.0.100-preview.2.22118.2-linux-x64.tar.gz) to build the regex test case on Intel, and can confirm that the resulting assembly now outputs "True" when run on s390x.

Thanks!

[stephentoub]

Thanks for confirming, @uweigand.