Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conflict resolution #2277

Merged
merged 4 commits into from
Apr 5, 2022
Merged

Conflict resolution #2277

merged 4 commits into from
Apr 5, 2022

Conversation

WardF
Copy link
Member

@WardF WardF commented Apr 5, 2022

#2222 with a few small conflicts resolved.

DennisHeimbigner and others added 4 commits February 8, 2022 20:53
re: Issue Unidata#2190

The primary purpose of this PR is to improve the utf8 support
for windows. This is persuant to a change in Windows that
supports utf8 natively (almost). The almost means that it is
still utf16 internally and the set of characters representable
by utf8 is larger than those representable by utf16.

This leaves open the question in the Issue about handling
the Windows 1252 character set.

This required the following changes:

1. Test the Windows build and major version in order to see if
   native utf8 is supported.
2. If native utf8 is supported, Modify dpathmgr.c to call the 8-bit
   version of the windows fopen() and open() functions.
3. In support of this, programs that use XGetOpt (Windows versions)
   need to get the command line as utf8 and then parse to
   arc+argv as utf8. This requires using a homegrown command line parser
   named XCommandLineToArgvA.
4. Add a utility program called "acpget" that prints out the
   current Windows code page and locale.

Additionally, some technical debt was cleaned up as follows:

1. Unify all the places which attempt to read all or a part
   of a file into the dutil.c#NC_readfile code.
2. Similary unify all the code that creates temp files into
   dutil.c#NC_mktmp code.
3. Convert almost all remaining calls to fopen() and open()
   to NCfopen() and NCopen3(). This is to ensure that path management
   is used consistently. This touches a number of files.
4. extern->EXTERNL as needed to get it to work under Windows.
@WardF WardF added the Conflict Resolved Indicates this is a different PR that needed a conflict resolved in order to merge. label Apr 5, 2022
@WardF WardF added this to the 4.9.0 milestone Apr 5, 2022
@WardF WardF self-assigned this Apr 5, 2022
@WardF WardF merged commit ac5c2f5 into Unidata:main Apr 5, 2022
@WardF WardF deleted the gh2222.wif branch April 5, 2022 17:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Conflict Resolved Indicates this is a different PR that needed a conflict resolved in order to merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants