Fix utf8_to_utf16 and utf16_to_utf8 for s390x#128577
Conversation
The converters return incorrect string when MINIPAL_TREAT_AS_LITTLE_ENDIAN is set true
|
@Dotnet-s390x build |
|
cc: @jkotas |
|
Build Queued.. To cancel the current build, please comment: |
|
@saitama951, was there any PAL test failing before this change? If not, could we add a case or two there which exercises it (that would fail without this fix)? Possible place of addition: It would help gain some confidence in the future, if someone refactors this code (e.g. with SIMD etc.). We refactored it in 2023 and seeing that we are only finding it out now is a bit worrying. :/ |
|
Build Successful |
|
@am11 I think the intent of MultiByteToWideChar, WideCharToMultiByte are supposed to be in native endian which worked fine even before this patch, It is only when minipal is forced to convert strings in LE order in big endian system that this failed. I think the eventpipe stuff forces things to write down into a .nettrace in little-endian order. |
|
You can cherry pick this commit main...am11:runtime:chore/utf-bigendian-tests. I don't have access to bigendian machine right now, but if it fails on main branch and passes with PR, it would suffice for minipal API coverage. |
I doubt that the Win32 PAL tests work on s390x. We can look into the testing separately. |
They work just fine #128394 (comment). |
|
@am11 after applying this patch I started to get this failure I have made endian changes to |
|
@Dotnet-s390x build |
|
Build Queued.. To cancel the current build, please comment: |
|
Please check the build logs: http://148.100.85.217:8080/job/dotnet-builds/81/console. |
The converters return incorrect string when MINIPAL_TREAT_AS_LITTLE_ENDIAN is set true on s390x
see: #128394 (comment)