Skip to content
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

Closed
neongreen opened this issue Jul 7, 2016 · 2 comments
Closed

Position tracking of headings is inconsistent #141

neongreen opened this issue Jul 7, 2016 · 2 comments

Comments

@neongreen
Copy link
Contributor

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):

> let Node _ DOCUMENT [n] = commonmarkToNode [] (T.pack "# hello") in n

Node (Just (PosInfo {startLine = 1, 
                     startColumn = 3, 
                     endLine = 1, 
                     endColumn = 7})) 
     (HEADING 1) 
     [Node Nothing (TEXT "hello") []]

Position info for a =====-style header does include the ===== (i.e. it ends at line 2, not line 1):

> let Node _ DOCUMENT [n] = commonmarkToNode [] (T.pack "hello\n=====") in n

Node (Just (PosInfo {startLine = 1, 
                     startColumn = 1,
                     endLine = 2,
                     endColumn = 5})) 
     (HEADING 1)
     [Node Nothing (TEXT "hello") []]

The latter behavior seems more correct to me and it'd be good if source positions for #-style headers behaved the same way.

@jgm
Copy link
Member

jgm commented Jul 7, 2016

+++ Artyom [Jul 07 16 14:38 ]:

The following demonstration uses Haskell bindings for cmark
(unfortunately, I don't know C so I'm unable to port the example to C;

You can do

cmark -t xml --sourcepos

to see what source positions the C library is assigning.

@neongreen
Copy link
Contributor Author

Thanks!

I built cmark (from Github) and fed it the following file:

# foo

bar
===

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 neongreen changed the title Position tracking of headers is inconsistent Position tracking of headings is inconsistent Jul 8, 2016
@jgm jgm closed this as completed in 005d6d0 Jul 12, 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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants