Update description with a bit more detail
Mon, Sep 13
Fri, Sep 10
Thu, Sep 9
If you can split it into a few changes that are easier to review, it would be helpful.
Wed, Sep 8
As discussed over slack, there is an edge case that needs to be addressed (the case where ps == nullptr on line 55 of wcsnrtombs and/or on line 61 of mbsnrtowcs).
Once that's fixed, LGTM. I've left several comments for a few more ways it could be tidied up, but none of them are functional changes.
Wed, Sep 1
Fri, Aug 20
Aug 18 2021
Update commit tags
I'd normally frown upon this since we generally don't clang-format whole files at once, but since the changes are pretty small, it might be OK to do that. But we definitely want to clang-format it right though.
Address Louis's comments
Aug 17 2021
Aug 4 2021
I will update D105910 with these test cases, so this can be closed
Given the nature of these changes, they're fairly low priority for us to get upstream right now, but I will come back to these at a later date to address the comments and get this into a state where it is suitable to merge
Jul 13 2021
Jul 7 2021
Jul 6 2021
Update PR based on internal discussions about whether to match targets based on
just zos or both s390 and zos.
Jun 18 2021
LGTM, but just out of curiosity, will this stay unsupported forever, or will this be implemented eventually?
Normally, we try to support things unless we have a fundamental reason why it can't be done (for example supporting exceptions on an embedded system). But it seems a bit strange to me to mark aligned allocation function tests as unsupported based on the *architecture* - instead I would have expected it to be marked as unsupported based on specific OS versions that do not implement the feature yet.
As of today z/OS does not support aligned allocation. Once it is supported we will be able to say it is only supported in z/OS X.Y and above. The tag "s390-zos" is more than an architecture tag. It is more of an OS tag. We have zLinux on s390 as well. The s390-zos tag only covers z/OS, not zLinux. We can change that name if it helps clarify some confusion.
Jun 17 2021
Updating with related changes instead of creating new PRs
Jun 14 2021
Update to address Louis's comments.
Jun 9 2021
Immediately after hitting submit I notice a few more things. Added them as comments too
If this is taken from windows, I will point out that, on windows wide characters are only 16 bits (on most systems, wchar_t is 32 bits). This may result in some assumptions in the implementation which aren't true for z/OS. I'm particularly concerned about line 39 potentially writing more than dest_remaining characters (TBH, I'm a little surprised this part works correctly on windows). This could result in writing past the end of dst (i.e. a buffer overflow). This would then be made even worse by dest_remaining -= char_size not setting dest to 0 at that point, and thus the ! dest_remaining check not triggering. Assuming it has the correct license, using the z/OS implementation of wcsrtombs as a reference might be better (unlike wcsnrtombs which is a POSIX extention, wcsrtombs is a part of the C and C++ standards).
Jun 7 2021
Jun 4 2021
Jun 2 2021
Jun 1 2021