You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 9, 2018. It is now read-only.
This means that building pdf2htmlEX will by default include the full path to these files in the resulting binaries because assert() uses the __FILE__ macro internally. This is problematic for two reasons:
the binary will look different when compiled on different systems with different build paths. This makes it harder to compare whether the produced binary matches the expected binary. For arguments why compiling software should yield the same results independent of who builds it read https://reproducible-builds.org/
the absolute path might contain sensitive information that the user building pdf2htmlEX might not want to disclose. By not including the build path in the resulting binaries, the user will not accidentally share the path.
I see two ways to fix the problem:
replace all calls to assert() by normal if/else constructs with the usual error handling
build the code with NDEBUG being defined by default
What do you think?
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi,
currently, the following files contain assert() calls:
This means that building pdf2htmlEX will by default include the full path to these files in the resulting binaries because assert() uses the
__FILE__
macro internally. This is problematic for two reasons:I see two ways to fix the problem:
assert()
by normal if/else constructs with the usual error handlingWhat do you think?
The text was updated successfully, but these errors were encountered: