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

patch for Windows MSVC from W32TeX #3

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

t-tk
Copy link

@t-tk t-tk commented Jul 24, 2021

I heard Akira Kakuto-san have decided to complete his contribution to the TeX community and have closed w32tex.org.
This pull request is the patch derived by @aminophen for Windows MS Visual C from Kakuto-san's W32TeX source code.
I expect the patch is also useful for other compilers mingw and cygwin on Windows.
I would like you to consider pulling it in the master.

The patch treats:

  • Unicode file names
  • path separator
  • long path name
  • UNC
  • file open by binary mode

@mojca
Copy link
Contributor

mojca commented Jul 26, 2021

Thanks a lot for submitting the patch.

I'm neither the author nor familiar with this code, but while we wait for the author to respond: do you perhaps have some minimal example demonstrating the problem that the patch is trying to address?

Ideally we would probably want to add some unit tests. It's of course not your job to write unit tests. It would however greatly help to have some more information that would be sufficient to add some unit tests.

Copy link
Collaborator

@paweljackowski paweljackowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your patch. I wrote pplib for luatex, I doubt it is used anywhere else. So I see no obstackles for such changes iff luatex team finds it usefull. If luatex team would like to have it in luatex, then I'd vote for merging this change to pplib master (with respect to some non-critical code comments I left)

return NULL;
wmode = get_wstring_from_mbstring(cp, mode, wmode=NULL);
if (wmode == NULL)
return NULL;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sanity, if wmode is NULL, wfilename should be freed before return.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is fixed by d315123

@@ -61,6 +61,11 @@

#include "utilmd5.h"

#ifdef _WIN32 /* --ak */
extern FILE *ppu8open(const char *filename, const char *mode);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO would be perfect if such redefinitions were in some dedicated place, like utildecl.h, utilplat.h or a new one, containing only platform-dependent code.

@@ -8,6 +8,11 @@
#include "utillog.h"
#include "utiliof.h"

#ifdef _WIN32 /* --ak */
FILE *ppu8open(const char *filename, const char *mode);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps there should be util_fopen() function explicitly called in other places, instead of hiding fopen() by a macro?


fnn = malloc(len + 10);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or meybe unsigned char fnn[MAX_PATH + 10]?

Copy link
Author

@t-tk t-tk Aug 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have found a document about very long path name:
https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd

In short, very long file name is available after the \\?\ prefix and it could be longer than MAX_PATH.
So, util_malloc() should be better.

return NULL;
}
if (wstr==NULL) {
wstr = malloc(sizeof(wchar_t)*(len+1));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO we should consequently use util_malloc(), as probably all code in pplib. afair there was two reasons to avoid direct calls to malloc():

  • easier replacement with some other base allocator (some day maybe)
  • low-level check for NULL (and rather brutal solution..)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand pplib defines util_malloc() at util/utilmem.c and is using util_malloc() instead of malloc().
I agree util_malloc() is better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants