fix(test): handle big-endian encoding in EncodeUCS2 test

[abhayagarwal-dev]

Problem
The EncodeUCS2 test in test/cpp/strings.cpp fails on big-endian architectures (s390x). char16_t string literals (like u"hello") are stored in host byte order (BE on s390x), but node::Encode(..., UCS2) expects LE input and applies an internal endianness swap on BE systems.

            process.processTicksAndRejections (node:internal/process/task_queues:77:11)
        found:  栀攀氀氀漀
        wanted: hello
        diff:   |
          FOUND:  栀攀氀氀漀
          WANTED: hello
                  ^ (at position = 0)
      ...

Solution
Convert each 16-bit code unit from BE to LE on big-endian platforms (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) before passing to node::Encode.
Compute buffer size dynamically (kNumChars * sizeof(uint16_t)).
Little-endian platforms (x86_64, arm64) are unaffected.

Test results
s390x (Big-Endian):

$ node ./node_modules/.bin/tap test/js/strings-test.js
ok test/js/strings-test.js .............................. 7/7
total ................................................... 7/7

ok

arm64(Little-Endian)

$ node ./node_modules/.bin/tap test/js/strings-test.js
ok test/js/strings-test.js .............................. 7/7
total ................................................... 7/7

ok

Full test suite:

$ npm test

> nan@2.28.0 test
> tap --gc --stderr test/js/*-test.js

ok test/js/accessors2-test.js ........................... 5/5
ok test/js/accessors-test.js ............................ 8/8
ok test/js/asyncprogressqueueworkerstream-test.js ....... 2/2
ok test/js/asyncprogressqueueworker-test.js ............. 7/7
ok test/js/asyncprogressworkersignal-test.js ............ 7/7
ok test/js/asyncprogressworkerstream-test.js ............ 2/2
ok test/js/asyncprogressworker-test.js .................. 7/7
ok test/js/asyncresource-test.js ........................ 8/8
ok test/js/asyncworkererror-test.js ..................... 4/4
ok test/js/asyncworker-test.js ........................ 10/10
ok test/js/buffer-test.js ............................... 9/9
ok test/js/bufferworkerpersistent-test.js ............... 8/8
ok test/js/callbackcontext-test.js ...................... 8/8
ok test/js/converters-test.js ......................... 33/33
ok test/js/error-test.js .............................. 61/61
ok test/js/gc-test.js ................................... 4/4
ok test/js/indexedinterceptors-test.js .................. 6/6
ok test/js/isolatedata-test.js .......................... 3/3
ok test/js/json-parse-test.js ........................... 9/9
ok test/js/json-stringify-test.js ..................... 23/23
ok test/js/makecallback-test.js ......................... 2/2
ok test/js/maybe-test.js ................................ 2/2
ok test/js/methodswithdata-test.js ...................... 9/9
ok test/js/morenews-test.js ........................... 17/17
ok test/js/multifile-test.js ............................ 3/3
ok test/js/namedinterceptors-test.js .................... 6/6
ok test/js/nancallback-test.js ........................ 20/20
ok test/js/nannew-test.js ............................. 95/95
ok test/js/news-test.js ............................... 53/53
ok test/js/objectwraphandle-test.js ................... 10/10
ok test/js/persistent-test.js ......................... 16/16
ok test/js/private-test.js .............................. 9/9
ok test/js/returnemptystring-test.js .................... 4/4
ok test/js/returnnull-test.js ........................... 4/4
ok test/js/returnundefined-test.js ...................... 4/4
ok test/js/returnvalue-test.js ........................ 10/10
ok test/js/setcallhandler-test.js ....................... 5/5
ok test/js/settemplate-test.js ........................ 23/23
ok test/js/strings-test.js .............................. 7/7
ok test/js/symbols-test.js .............................. 3/3
ok test/js/threadlocal-test.js .......................... 8/8
ok test/js/trycatch-test.js ............................. 3/3
ok test/js/typedarrays-test.js ........................ 29/29
ok test/js/weak2-test.js ................................ 4/4
ok test/js/weak-test.js ................................. 6/6
ok test/js/wrappedobjectfactory-test.js ................. 5/5
total ............................................... 581/581

ok

[abhayagarwal-dev]

@kkoopa Could you approve the github workflow action when you get a chance? Thank you!

[abhayagarwal-dev]

@kkoopa could you take a look at this PR and merge it if everything looks ok? Thank you.

[kkoopa]

Hi, I am wondering about what to do with ancient versions of Node and whether this could be accommodated somehow.

…

On Sun, Sep 27, 2026, 00:18 abhayagarwal-dev ***@***.***> wrote: *abhayagarwal-dev* left a comment (nodejs/nan#1023) <#1023 (comment)> @kkoopa <https://github.com/kkoopa> could you take a look at this PR and merge it if everything looks ok? Thank you. — Reply to this email directly, view it on GitHub <#1023?email_source=notifications&email_token=AA7JXKJEMM5BHWSPAMV7JND5RAXBJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOBUHE4TMNJTGY42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5849965369>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7JXKNFFZRQIODCBPB2R335RAXBJAVCNFSNUABEKJSXA33TNF2G64TZHMYTCNJUGU4TEOB3JFZXG5LFHM2TINZVGMYDQMZVHGQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AA7JXKPXZIVPJAZFYF4X7BT5RAXBJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOBUHE4TMNJTGY42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AA7JXKKDAFPKLYWNLHCKSJ35RAXBJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOBUHE4TMNJTGY42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[abhayagarwal-dev]

Hi @kkoopa, thanks for the review!

__BYTE_ORDER__ and__ORDER_BIG_ENDIAN__are GCC/Clang predefined macros available since GCC 4.6 , well within any Node version NAN has ever supported. On LE platforms the #if branch is never taken so behaviour is unchanged. On MSVC (Windows, always LE), the macro isn't defined so the #else path is taken. No new compiler requirements beyond what C++11 already mandates for the existing char16_t/u"" literals in this file.

[kkoopa]

I If I remember correctly, C++11 was not required before V8 4.3, and then there is Encode in nan_string_bytes.h, might well be some other things lurking as well. The behavior has changed several times over the years.

…

On Sun, Sep 27, 2026, 11:06 Abhay Agarwal ***@***.***> wrote: *abhayagarwal-dev* left a comment (nodejs/nan#1023) <#1023 (comment)> Hi @kkoopa <https://github.com/kkoopa>, thanks for the review! __BYTE_ORDER__ and__ORDER_BIG_ENDIAN__are GCC/Clang predefined macros available since GCC 4.6 , well within any Node version NAN has ever supported. On LE platforms the #if branch is never taken so behaviour is unchanged. On MSVC (Windows, always LE), the macro isn't defined so the #else path is taken. No new compiler requirements beyond what C++11 already mandates for the existing char16_t/u"" literals in this file. — Reply to this email directly, view it on GitHub <#1023?email_source=notifications&email_token=AA7JXKJY5IKJUUAKDJS3LWL5RDC77A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOBVGQYDMMZZGQYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5854063940>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7JXKKH6URQAZ4225SRREL5RDC77AVCNFSNUABEKJSXA33TNF2G64TZHMYTCNJUGU4TEOB3JFZXG5LFHM2TINZVGMYDQMZVHGQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AA7JXKJOEIWPY6RRXJCOMR35RDC77A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOBVGQYDMMZZGQYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AA7JXKMDMPCWI77A5KL7YTL5RDC77A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOBVGQYDMMZZGQYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[abhayagarwal-dev]

Thanks for the context!
Looking at nan.h, for NODE_MODULE_VERSION <= NODE_0_10_MODULE_VERSION the call falls through to imp::Encode in nan_string_bytes.h which does no endianness swap and expects host byte order ,so the swap I added would be wrong there.
I can add a NODE_MODULE_VERSION > NODE_0_10_MODULE_VERSION guard to the #if condition to be safe.

Would that address your concern?

[kkoopa]

I would like the behavior to be consistent across versions without the need for doing conditionals in user code, if it is needed in tests, it is needed in user code. Would not the proper fix be to backport the new endianness swap behavior via NAN, thereby fixing it for all without needing a bunch of #ifs in tests or user code?

…

On Sun, Sep 27, 2026, 11:27 Abhay Agarwal ***@***.***> wrote: *abhayagarwal-dev* left a comment (nodejs/nan#1023) <#1023 (comment)> Thanks for the context! Looking at nan.h, for NODE_MODULE_VERSION <= NODE_0_10_MODULE_VERSION the call falls through to imp::Encode in nan_string_bytes.h which does no endianness swap and expects host byte order ,so the swap I added would be wrong there. I can add a NODE_MODULE_VERSION > NODE_0_10_MODULE_VERSION guard to the #if condition to be safe. Would that address your concern? — Reply to this email directly, view it on GitHub <#1023?email_source=notifications&email_token=AA7JXKLIIPN2VTB2GEHF6PT5RDFQ3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOBVGQZDAMJSGY2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5854201264>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7JXKNYLKMEZHNCNLGDWRD5RDFQ3AVCNFSNUABEKJSXA33TNF2G64TZHMYTCNJUGU4TEOB3JFZXG5LFHM2TINZVGMYDQMZVHGQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AA7JXKJ3SWWJPV3CTACMNHT5RDFQ3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOBVGQZDAMJSGY2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AA7JXKLS7PXJA2SOOQR6JBT5RDFQ3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOBVGQZDAMJSGY2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[abhayagarwal-dev]

That makes complete sense. I have moved the endianness handling directly into nan.h (Nan::Encode / Nan::TryEncode) across all supported Node.js version branches for Encoding == UCS2 on big-endian platforms.

This ensures consistent behavior across all Node versions without requiring any #ifdef conditionals in tests or consumer/user code. The test in test/cpp/strings.cpp remains clean and standard.

I've updated the PR branch with this change.

[abhayagarwal-dev]

Could you approve the workflow for the changes so it can be tested? Thank you.

[abhayagarwal-dev]

@kkoopa, all 23 checks are passing
Let me know if you have any further feedback on this updated approach.