Age | Commit message (Collapse) | Author |
|
NetBSD build fixes
|
|
We need to cast value passed to isspace(3) to unsigned char to explicitly
prevent possibly undefined behavior.
/tmp/pkgsrc-tmp/wip/cmark/work/cmark-0.24.1/src/commonmark.c: In function 'S_render_node':
/tmp/pkgsrc-tmp/wip/cmark/work/cmark-0.24.1/src/commonmark.c:273:9: warning: array subscript has type 'char' [-Wchar-subscripts]
(code_len > 2 && !isspace(code[0]) &&
^
/tmp/pkgsrc-tmp/wip/cmark/work/cmark-0.24.1/src/commonmark.c:274:10: warning: array subscript has type 'char' [-Wchar-subscripts]
!(isspace(code[code_len - 1]) && isspace(code[code_len - 2]))) &&
^
/tmp/pkgsrc-tmp/wip/cmark/work/cmark-0.24.1/src/commonmark.c:274:10: warning: array subscript has type 'char' [-Wchar-subscripts]
CTYPE(3) Library Functions Manual CTYPE(3)
NAME
isalpha, isupper, islower, isdigit, isxdigit, isalnum, isspace, ispunct,
isprint, isgraph, iscntrl, isblank, toupper, tolower, - character
classification and mapping functions
LIBRARY
Standard C Library (libc, -lc)
CAVEATS
The first argument of these functions is of type int, but only a very
restricted subset of values are actually valid. The argument must either
be the value of the macro EOF (which has a negative value), or must be a
non-negative value within the range representable as unsigned char.
Passing invalid values leads to undefined behavior.
NetBSD 7.99 February 25, 2015 NetBSD 7.99
|
|
|
|
Very minor documentation typo
|
|
|
|
blocks: More documentation and refactoring
|
|
|
|
|
|
This reverts commit 4d2d486333c358eb3adf3d0649163e319a3b8b69.
This commit caused a valgrind invalid read.
==29731== Invalid read of size 4
==29731== at 0x40500E: S_process_line (blocks.c:1050)
==29731== by 0x403CF7: S_parser_feed (blocks.c:526)
==29731== by 0x403BC9: cmark_parser_feed (blocks.c:494)
==29731== by 0x433A95: main (main.c:168)
==29731== Address 0x51d5b60 is 64 bytes inside a block of size 128 free'd
==29731== at 0x4C27D4E: free (vg_replace_malloc.c:427)
==29731== by 0x4015F0: S_free_nodes (node.c:134)
==29731== by 0x401634: cmark_node_free (node.c:142)
==29731== by 0x4033B1: finalize (blocks.c:259)
==29731== by 0x40365E: add_child (blocks.c:337)
==29731== by 0x4046D8: try_new_container_starts (blocks.c:836)
==29731== by 0x404F12: S_process_line (blocks.c:1015)
==29731== by 0x403CF7: S_parser_feed (blocks.c:526)
==29731== by 0x403BC9: cmark_parser_feed (blocks.c:494)
==29731== by 0x433A95: main (main.c:168)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It's a programming error if the type is out of range.
|
|
https://github.com/MathieuDuponchelle/cmark into MathieuDuponchelle-refactor-S_processLine
|
|
|
|
It's the core of the program and I had too much trouble making
sense of it, two loops with many cases and other code
interspersed hurt my head.
All the tests still passed before rebasing, now I've got the
exact same set of issues as master.
|
|
|
|
|
|
|
|
See #102.
|
|
|
|
Version <= 1.13.7 don't allow the `-8` option.
Closes #102.
|
|
|
|
|
|
|
|
|
|
|
|
E.g. in
```
- foo
<TAB><TAB>bar
```
we should consume two spaces from the second tab,
including two spaces in the code block.
|
|
This keeps track of when we have gotten partway
through a tab when consuming initial indentation.
|
|
|
|
Closes #101.
This patch fixes `S_advance_offset` so that it doesn't gobble
a tab character when advancing less than the width of a tab.
|
|
This helps compiling on systems like luarocks that don't
have all the cmake configuration goodness.
Thanks to @carlmartus
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We try not to escape punctuation unless we absolutely have
to. So, `)` and `.` are no longer escaped whenever they
occur after digits; now they are only escaped if they are
geuninely in a position where they'd cause a list item.
This required a couple changes to render.c.
- `renderer->begin_content` is only set to false AFTER a
string of digits at the beginning of the line. (This is
slightly unprincipled.)
- We never break before a numeral (also slightly unprincipled).
|
|
|
|
following list or code block.
This has several advantages. First, the two blank lines breaks
out of list syntax is still controversial in CommonMark.
And it isn't used in other implementations. HTML comments
will always work.
Second, two blank lines breaks out of all lists; an HTML
comment can be used to break out of just one level of nesting.
|
|
|
|
This makes the output compatible with more implementations.
|