Age | Commit message (Collapse) | Author |
|
Closes #263.
|
|
Newer versions of CMake attempt to query the system for information about the VS
2017 installation. Unfortunately, this query fails on non-Windows systems when
cross-compiling:
cmake_host_system_information does not recognize <key> VS_15_DIR
CMake will not find these system libraries on non-Windows hosts anyways, and we
were silencing the warnings, so simply omit the installation when
cross-compiling to Windows.
|
|
|
|
These affect both parsing and writing commonmark.
|
|
Added regression test.
See commonmark/CommonMark#527.
|
|
We were needlessly redoing things we'd already done.
Now we skip the work if the first nonspace is greater
than the current offset.
This fixes pathological slowdown with deeply nested
lists (#255). For N = 3000, the time goes from over
17s to about 0.7s.
Thanks to @mity for diagnosing the problem.
|
|
To conform to recent spec change.
|
|
See commonmark/CommonMark#487.
|
|
This fixes a recently added failing spec test case.
Previously spaces were being allowed in unquoted attribute
values; no we forbid them.
|
|
See commonmark/CommonMark#497.
|
|
Fixes issue #247.
|
|
> 32 nested balanced parens in a link is bananas
|
|
|
|
Fixes installation error under some CMake versions, notably kalakris'
CMake backport often used with Travis.
|
|
Due to a mistake, 0.28.1 installed libcmark.a into include/.
Closes #238.
|
|
For some reason this wasn't getting set in processing
libcmark.pc.in, and we were getting the wrong entry in libcmark.pc.
(See #236)
The new approach sets an internal libdir variable to
lib${LIB_SUFFIX}. This variable is used both to set the
install destination and in the libcmark.pc.in template.
Closes #236.
However, I'd welcome comments from @juhp who originally
added CMAKE_INSTALL_LIBDIR in #185. I think that the new
system should work fine with Fedora, since LIB_SUFFIX will
be set appropriately, but some testing is in order.
|
|
|
|
|
|
|
|
Closes #227.
|
|
|
|
|
|
This option was added in 04726a7 (Added `CMARK_OPT_VALIDATE_UTF8`
option. - 2015-06-16) but not "documented".
|
|
|
|
Commit 14ea489f5dd6e3d07e23f104d6c9ce441d05751b
|
|
|
|
Use unsigned integer when shifting
|
|
A UBSAN warning can be triggered when handling a long sequence of backticks:
src/commonmark.c:98:20: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
which can be triggered by:
```
| a | b |
| --- | --** `c```````````````````````````````- |
| c | `|d` \| e |
```
|
|
A UBSAN warning can be triggered because the link title is an empty string:
src/inlines.c:113:20: runtime error: null pointer passed as argument 2, which is declared to never be null
which can be triggered by:
```
[f]:_
[f]
```
The length of the memcpy is zero so the NULL pointer is not dereferenced but it
is still undefined behaviour.
|
|
This also brings the code into closer alignment with the wording
of the spec.
See jgm/CommonMark#467.
|
|
Closes #211.
Found by google/oss-fuzz:
https://oss-fuzz.com/v2/testcase-detail/4686992824598528
|
|
We got an array overflow in enumerated lists nested more than
10 deep with start number =/= 1.
Found by google/oss-fuzz.
https://oss-fuzz.com/v2/testcase-detail/5546760854306816
This commit also ensures that we don't try to set `enum_` counters
that aren't defined by LaTeX (generally up to enumv).
Closes #210.
|
|
echo '[](xx:)' | ./build/src/cmark -t latex
Segmentation fault: 11
|
|
This can be run locally with `make libFuzzer` but the harness will be
integrated into oss-fuzz for large-scale fuzzing.
|
|
See https://github.com/jgm/cmark/issues/206.
|
|
|
|
|
|
Revert "Remove normalize as an option per #190"
|
|
E.g. cmark_node_get_url on a non-link or image.
Closes #155.
|
|
Only ascii punctuation characters are escapable,
per the spec.
Closes #192.
|
|
Closes #193.
|
|
as documented!
Closes #202.
|
|
|
|
|
|
|
|
Note, however, that this may not be needed at all:
the old code would have gone into an infinite loop
if the delimiter stack were not already freed.
If we can prove that the delimiter stack is empty
at this point, we could remove this; on the other hand,
it may not hurt to keep it here defensively.
Closes #189.
|
|
|
|
|
|
Closes #188.
@nwellnhof - could you have a look and let me know if you
think this is a bad idea or could be improved?
|
|
needed for multilib distros like Fedora
|