-
-
Notifications
You must be signed in to change notification settings - Fork 549
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Position tracking of headings is inconsistent #141
Comments
+++ Artyom [Jul 07 16 14:38 ]:
You can do
to see what source positions the C library is assigning. |
Thanks! I built cmark (from Github) and fed it the following file:
It produced the following output (which exhibits the same behavior as my original Haskell demonstration): <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document SYSTEM "CommonMark.dtd">
<document sourcepos="1:1-4:3" xmlns="http://commonmark.org/xml/1.0">
<heading sourcepos="1:3-1:5" level="1">
<text>foo</text>
</heading>
<heading sourcepos="3:1-4:3" level="1">
<text>bar</text>
</heading>
</document> |
neongreen
changed the title
Position tracking of headers is inconsistent
Position tracking of headings is inconsistent
Jul 8, 2016
CyberShadow
pushed a commit
to CyberShadow/cmark
that referenced
this issue
Apr 1, 2021
* fix(table): recoginse-without-empty-line (commonmark#141) * fix(table): fix bufsize_t not convert to uint16_t * fix(table): fix uint16_6 not convert to int * fix(table): fix uint16_6 not convert to int * fix(table): clear unused type conversion * restore whitespace * Always free `paragraph_content` `cmark_node_set_string_content` allocates and copies the data in `paragraph_content` so it is not needed afterwards. ``` ================================================================= ==14==ERROR: LeakSanitizer: detected memory leaks Direct leak of 24 byte(s) in 1 object(s) allocated from: 0 0x4dd330 in calloc /src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:97 1 0x59e243 in xcalloc /src/octofuzz/src/cmark.c:18:15 2 0x58fd75 in unescape_pipes /src/octofuzz/extensions/table.c:95:39 3 0x58fd75 in try_inserting_table_header_paragraph /src/octofuzz/extensions/table.c:187 4 0x58fd75 in try_opening_table_header /src/octofuzz/extensions/table.c:254 5 0x58fd75 in try_opening_table_block /src/octofuzz/extensions/table.c:370 6 0x5b22d5 in open_new_blocks /src/octofuzz/src/blocks.c:1275:27 7 0x5b22d5 in S_process_line /src/octofuzz/src/blocks.c:1465 8 0x5aa7f0 in cmark_parser_finish /src/octofuzz/src/blocks.c:1492:5 9 0x58f2fc in LLVMFuzzerTestOneInput /src/octofuzz/test/cmark-fuzz.c:46:23 Indirect leak of 8 byte(s) in 1 object(s) allocated from: 0 0x4dd580 in realloc /src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:107 1 0x59e2d3 in xrealloc /src/octofuzz/src/cmark.c:27:19 2 0x640364 in cmark_strbuf_grow /src/octofuzz/src/buffer.c:57:31 3 0x640364 in cmark_strbuf_init /src/octofuzz/src/buffer.c:31 4 0x58fd8b in unescape_pipes /src/octofuzz/extensions/table.c:98:3 5 0x58fd8b in try_inserting_table_header_paragraph /src/octofuzz/extensions/table.c:187 6 0x58fd8b in try_opening_table_header /src/octofuzz/extensions/table.c:254 7 0x58fd8b in try_opening_table_block /src/octofuzz/extensions/table.c:370 8 0x5b22d5 in open_new_blocks /src/octofuzz/src/blocks.c:1275:27 9 0x5b22d5 in S_process_line /src/octofuzz/src/blocks.c:1465 10 0x5aa7f0 in cmark_parser_finish /src/octofuzz/src/blocks.c:1492:5 11 0x58f2fc in LLVMFuzzerTestOneInput /src/octofuzz/test/cmark-fuzz.c:46:23 SUMMARY: AddressSanitizer: 32 byte(s) leaked in 2 allocation(s). ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following demonstration uses Haskell bindings for cmark (unfortunately, I don't know C so I'm unable to port the example to C; I assume the bindings are faithful and don't mess anything up).
Position info for a
#
-style header doesn't include the#
(i.e. it starts from column 3 instead of column 1):Position info for a
=====
-style header does include the=====
(i.e. it ends at line 2, not line 1):The latter behavior seems more correct to me and it'd be good if source positions for
#
-style headers behaved the same way.The text was updated successfully, but these errors were encountered: