These CFLAGS overrides aren't necessary now that we default to C17. These libraries all compile correctly as C17.
Depends on D229576
Differential Revision: https://phabricator.services.mozilla.com/D229577
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
- Add missing include directives and forward declarations.
- Remove some extra include directives.
- Add missing namespace qualifications.
- Move include directives out of namespace in toolkit/xre/GlobalSemaphore.h
Differential Revision: https://phabricator.services.mozilla.com/D98894
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Include stdio.h before redefining ftello and fseeko to avoid clobbering the ftello() and fseeko() function declarations in MinGW's stdio.h.
I don't know why my change to compile libmar as C11 (bug 1653182) caused this ftello/fseeko problem. From my inspection of MinGW's stdio.h, this problem should have already been happening!
Differential Revision: https://phabricator.services.mozilla.com/D85665
static_assert is available in both C++11 and C11. While C++11's static_assert is a keyword, C11's static_assert is a macro defined in assert.h (that expands to the C11 keywoard _Static_assert). libar's header files are included in both C and C++ code, so we must #include assert.h to use static_assert.
https://en.cppreference.com/w/c/language/_Static_assert
Differential Revision: https://phabricator.services.mozilla.com/D83736
When we build mar, there is no reason not to build signmar as well. It
used to be optional because not all platforms were supported, but they
are now.
... except when building the newly added tools/update-packaging,
which builds the mar tool as a standalone thing, and building signmar
as well causes complications.
Differential Revision: https://phabricator.services.mozilla.com/D36992
Added defines to mar_extract.c, mar_read.c, bsdiff.c so they use the ISO C and C++ conformant name.
Ran clang format on bspatch.cpp and the files under modules/libmar except for nss_secutil.c and nss_secutil.h since they are copies of nss code.
Disallows files from referencing the same bytes in the content blocks of a MAR
file by storing a list of structs containing a file's byte offsets and lengths.
A list was chosen since the cap of 256 files wouldn't produce considerable
overhead when extracting/reading/searching/etc through the archive.
Removing the ability for a MAR file to reference the same content block
repeatedly seems like a better solution than what was suggested in the BLRG
report. (limiting the number of files or checking for overly large
decompressed files)
Allows us to prohibit this type of file bomb while only losing an attribute
of the MAR file format that wasn't being leveraged. The fix is applied in
mar_enum_items and mar_find_item so that the manifest the updater uses is
equally safeguarded as the mar host tool.
Differential Revision: https://phabricator.services.mozilla.com/D11706
Make CityHash64, CityHash64WithSeed, and CityHash64WithSeeds usable from C code
Remove unnecessary includes from mar_read.c as well
Add DisableStlWrapping to mar tool's moz.build to fix linkage break when
building in Windows with MSVC
Differential Revision: https://phabricator.services.mozilla.com/D10774
Only a single type of additional block has ever been defined for the MAR
archive format and only a single block of that type is needed per file.
Limiting ourselves to reading only that until we define more seems
sensible.
Move additionalBlockSize check before first fread
Add MAXADDITIONALBLOCKSIZE as a constant for checking block sizes
Differential Revision: https://phabricator.services.mozilla.com/D10797
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
The index section of a MAR archive file contains several fixed-length fields
and also variable-length names for each file in the archive, terminated by a
null byte. Since that makes the length of the index variable, the length of the
entire index is also provided in the file.
When libmar opens a file, it allocates a buffer with the length given in the
file and reads the index from the file into that buffer.
mar_consume_index() then parses the entire index from that copy,
trying to make sure it doesn't read past the buffer it was given.
The length of the buffer is given to mar_consume_index()
by providing it a pointer to one byte past the end of the buffer.
However, mar_consume_index() treats this pointer as pointing *to* the end.
Therefore, it is possible for a malformed MAR file (one where the stated length
is less than the real length) to trigger a read of one byte beyond the
allocated memory.
Fix this by failing the parse when we reach the buffer end pointer minus one,
instead of when we reach that address itself.
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
Sylvestre Ledru