Add table parser #11
Add table parser #11
Conversation
it breaks paragraph handling
pointer arithmetic are only allowed to go 1 past the end of the array. going any further than that is UB. char buf[8]; char *p = buf + sizeof buf; /* OK to compute, not ok to dereference */ char *q = buf + sizeof buf + 1; /* INVALID! neither OK compute nor dereference */ > If both the pointer operand and the result point to elements of the > same array object, or one past the last element of the array object, > the evaluation shall not produce an overflow; otherwise, the behavior > is undefined. ref: https://port70.net/~nsz/c/c11/n1570.html#6.5.6p8
Scratch that, just noticed that the cells aren't properly aligned on the first table. |
|
First time seeing |
inrow is assigned `-1` to indicate weather it's inside heading or not. however "plain char" is not guaranteed to be signed. explicitly use `signed char` instead. > whether a ''plain'' char is treated as signed is > implementation-defined. ref: https://port70.net/~nsz/c/c11/n1570.html#6.3.1.1p3
| <p>And here is another table</p> | ||
| <table> | ||
| <tr><th>Heading 1 </th><th>Some other heading </th></tr> | ||
| <tr><td>I am a table cell. </td><td>Me too! </td></tr> |
There was a problem hiding this comment.
Both in the heading and the entries, we retain any trailing white-spaces. Most other converters strip any trailing white-spaces.
most other parsers either use `align` or use `style="text-align: "`
The align attribute is obsolete and not valid HTML5, see https://html.spec.whatwg.org/multipage/obsolete.html#non-conforming-features.
|
One more note, a lot of the other parsers allow the table to be indented 1 while our parser I think being strict is fine because it's simpler. So the current behavior is OK by me until/unless CommonMark has a specification for table syntax. Pointing it out just in case. Footnotes |
By adding the code from #5.
Remaining TODO:
Closes #5.