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.
Fail if blob start plus length overflows; or if blob length
is greater than 2GB. It takes a while for fonts to get to that
size. In the mean time, it protects against bugs like this:
http://www.icu-project.org/trac/ticket/11450
Also avoids some weird issues with 32bit vs 64bit systems
as we accept length as unsigned int. As such, a length of
-1 will cause overflow on 32bit machines, but happily
accepted on a 64bit machine. Avoid that.
Should move these out of the public header...
We're "clean" of introspection warnings now. Remaining ones are about
graphite2 / freetype types not being introspectable.
This fixes a design bug with sanitize and sub-blobs that can
cause crashes. Jonathan and I found and debugged this issue
when we tested a corrupt font with the md5sum / filename:
ea395483d37af0cb933f40689ff7b60a. Two hours of intense
debugging we found out that the font has overlapping GSUB/GPOS
tables, and as such, sanitizing the second table can modify
the first one, which can cause all kinds of undefined behavior.
The correct way to fix this is to make sure sub-blobs are
always created readonly, since we consider the parent blob
to be a shared resource and can't modify it, even if it *is*
writable.
This essentially makes the READONLY_MAY_MAKE_WRITABLE mode
unused... Maybe we should simply remove / deprecate it.
Ebrahim Byagowi
Behdad Esfahbod
Bruce Mitchener
Ting-Wei Lan