Use the WINAPI_PARTITION macro to filter desktop/app flavors.
We use a negated desktop check because the default (for mingw-w64 at
least) is to allow all API by combining desktop + app partitions.
This causes build failures if we were to filter using
WINAPI_PARTITION(WINAPI_FAMILY_APP) because it would always be true, but
those API also require Windows 8 or later, while we only require Vista
Fixes warnings like
../src/hb-blob.cc:572:47: warning: 'WINAPI_FAMILY_PC_APP' is not defined, evaluates to 0 [-Wundef]
#if defined(WINAPI_FAMILY) && (WINAPI_FAMILY==WINAPI_FAMILY_PC_APP || WINAPI_FAMILY==WINAPI_FAMILY_PHONE_APP)
^
../src/hb-blob.cc:572:86: warning: 'WINAPI_FAMILY_PHONE_APP' is not defined, evaluates to 0 [-Wundef]
#if defined(WINAPI_FAMILY) && (WINAPI_FAMILY==WINAPI_FAMILY_PC_APP || WINAPI_FAMILY==WINAPI_FAMILY_PHONE_APP)
If the size of opened file is zero, try opening resource fork by
appending "/..namedfork/rsrc" to the file name. This is guarded with
__APPLE__ ifdef and uses _PATH_RSRCFORKSPEC macro from sys/paths.h.
Defining HB_NO_RESOURCE_FORK will disable this fallback.
Fixes https://github.com/harfbuzz/harfbuzz/issues/2383
We never rely on that being equal to readonly. Just not being
writable. Maybe not even that given that the object is inert.
In prep for next commit, using default null pool.
* Handle EINTR on fallback reader
* Increase fallback reader limitation size limitation to 2 << 28
* Ensure _O_BINARY does exist if MMAP is used on Windows
(maybe superfluous but makes me more confident)
With this hb-view/hb-shape support pipes and possibly socket and named pipe
also, anything fails just on mmap.
We can later do the same for Windows also.
This however reveals two issues, the fact most of our bots don't have HAVE_MMAP and using
this instead the other fread/fopen reader can make failure on CI. I should look at them separately
this change however is very low risk I believe.
"writable" is not in use and probably we can go in the reverse direction
and remove the flags that are useful for enabled writable, this is just
for the sake of completeness however.
This makes it compatible with ARMCC which I had access in
a collaboration with @imgtec, thanks!
Basically hb_blob_create_from_file features three code paths,
mmap, Win32 and fallback.
We had fallback implementation even before this but it was relied
to "open" which is not available on some environments. This change
improved the situtation by using only fopen and friends for
fallback path.
Interestingly we could use "open" on Windows but in fact it was
emulated by MSVCRT so I've completely split that from Unix path
now that we have a distinct path for fallback path also.