1 # mdcode: extract C code from a _markdown_ file.
3 _markdown_ is a popular format for simple text markup which can easily
4 be converted to HTML. As it allows easy indication of sections of
5 code, it is quite suitable for use in literate programming. This file
6 is an example of that usage.
8 The code included below provides two related functionalities.
9 Firstly it provides a library routine for extracting code out of a
10 _markdown_ file, so that other routines might make use of it.
12 Secondly it provides a simple client of this routine which extracts
13 1 or more C-language files from a markdown document so they can be
14 passed to a C compiler. These two combined to make a tool that is needed
15 to compile this tool. Yes, this is circular. A prototype tool was
16 used for the first extraction.
18 The tool provided is described as specific to the C language as it
21 ##### Example: a _line_ command
23 #line __line-number__ __file-name__
25 lines so that the C compiler will report where in the markdown file
26 any error is found. This tool is suitable for any other language
27 which allows the same directive, or will treat it as a comment.
31 Literate programming is more than just including comments with the
32 code, even nicely formatted comments. It also involves presenting the
33 code in an order that makes sense to a human, rather than an order
34 that makes sense to a compiler. For this reason a core part of any
35 literate programming tool is the ability to re-arrange the code found
36 in the document into a different order in the final code file - or
37 files. This requires some form of linkage to be encoded.
39 The approach taken here is focused around section headings - of any
42 All the code in any section is treated as a single sequential
43 collection of code, and is named by the section that it is in. If
44 multiple sections have the same name, then the code blocks in all of
45 them are joined together in the order they appear in the document.
47 A code section can contain a special marker which starts with 2
49 The text after the marker must be the name of some section which
50 contains code. Code from that section will be interpolated in place
51 of the marker, and will be indented to match the indent of the marker.
53 It is not permitted for the same code to be interpolated multiple
54 times. Allowing this might make some sense, but it is probably a
55 mistake, and prohibiting it make some of the code a bit cleaner.
57 Equally, every section of code should be interpolated at least once -
58 with one exception. This exception is imposed by the
59 tool, not the library. A different client could impose different
60 rules on the names of top-level code sections.
62 One example of the exception we have already seen. A section name
63 starting __Example:__ indicates code that is not to be included in the
64 final product. Any leading word will do, providing there is a space,
65 and the first space is preceded by a colon, that section name will be
68 A special case of this exception exists for the leading word
69 __File__. These sections are the top level code sections and they
70 will be written to the named file. Thus a section named
71 __File: foo__ should not be referenced by another section, and its
72 contents after all references are expanded will be written to the file
75 Any section containing code that does not start __Word:__
76 must be included in some other section exactly once.
80 Allowing multiple top level code sections which name different files
81 means that one _markdown_ document can describe several files. This
82 is very useful with the C language where a program file and a header
83 file might be related. For the present document we will have a header
84 file and two code files, one with the library content and one for the
87 It will also be very convenient to create a `makefile` fragment to
88 ensure the code is compiled correctly. A simple `make -f mdcode.mk`
89 will "do the right thing".
95 mdcode.h libmdcode.c md2c.c mdcode.mk : mdcode.mdc
103 ## exported functions
105 ### File: libmdcode.c
114 ## internal functions
119 libmdcode.o : libmdcode.c mdcode.h
120 $(CC) $(CFLAGS) -c libmdcode.c
137 md2c : md2c.o libmdcode.o
138 $(CC) $(CFLAGS) -o md2c md2c.o libmdcode.o
139 md2c.o : md2c.c mdcode.h
140 $(CC) $(CFLAGS) -c md2c.c
144 As the core purpose of _mdcode_ is to discover and re-arrange blocks
145 of text, it makes sense to map the whole document file into memory and
146 produce a data structure which lists various parts of the file in the
147 appropriate order. Each node in this structure will have some text
148 from the document, a child pointer, and a next pointer, any of which
149 might not be present. The text is most easily stored as a pointer and a
150 length. We'll call this a `text`
152 A list of these `code_nodes` will belong to each section and it will
153 be useful to have a separate `section` data structure to store the
154 list of `code_nodes`, the section name, and some other information.
156 This other information will include a reference counter so we can
157 ensure proper referencing, and an `indent` depth. As referenced
158 content can have an extra indent added, we need to know what that is.
159 The `code_node` will also have an `indent` depth which eventually gets
160 set to the sum for the indents from all references on the path from
163 Finally we need to know if the `code_node` was recognised by being
164 indented or not. If it was, the client of this data will want to
165 strip of the leading tab or 4 spaces. Hence a `needs_strip` flag is
177 struct code_node *code;
178 struct section *next;
186 struct code_node *next;
187 struct section *child;
194 struct code_node *last;
199 You will note that the `struct psection` contains an anonymous `struct
200 section` embedded at the start. To make this work right, GCC
201 requires the `-fplan9-extensions` flag.
203 ##### File: mdcode.mk
205 CFLAGS += -fplan9-extensions
207 ### Manipulating the node
209 Though a tree with `next` and `child` links is the easiest way to
210 assemble the various code sections, it is not the easiest form for
211 using them. For that a simple list would be best.
213 So once we have a fully linked File section we will want to linearize
214 it, so that the `child` links become `NULL` and the `next` links will
215 find everything required. It is at this stage that the requirements
216 that each section is linked only once becomes import.
218 `code_linearize` will merge the `code_node`s from any child into the
219 given `code_node`. As it does this it sets the 'indent' field for
222 Note that we don't clear the section's `last` pointer, even though
223 it no longer owns any code. This allows subsequent code to see if a
224 section ever had any code, and to report an error if a section is
225 referenced but not defined.
227 ##### internal functions
229 static void code_linearize(struct code_node *code)
232 for (t = code; t; t = t->next)
234 for (; code; code = code->next)
236 struct code_node *next = code->next;
237 struct psection *pchild =
238 (struct psection *)code->child;
239 int indent = pchild->indent;
240 code->next = code->child->code;
241 code->child->code = NULL;
243 for (t = code; t->next; t = t->next)
244 t->next->indent = code->indent + indent;
249 Once a client has made use of a linearized code set, it will probably
252 void code_free(struct code_node *code)
255 struct code_node *this;
257 code_linearize(code);
264 ##### exported functions
266 void code_free(struct code_node *code);
268 ### Building the tree
270 As we parse the document there are two things we will want to do to
271 node trees: add some text or add a reference. We'll assume for now
272 that the relevant section structures have been found, and will just
273 deal with the `code_node`.
275 Adding text simply means adding another node. We will never have
276 empty nodes, even if the last node only has a child, new text must go
279 ##### internal functions
281 static void code_add_text(struct psection *where, struct text txt,
282 int line_no, int needs_strip)
287 n = malloc(sizeof(*n));
290 n->line_no = line_no;
291 n->needs_strip = needs_strip;
295 where->last->next = n;
301 However when adding a link, we might be able to include it in the last
302 `code_node` if it currently only has text.
304 void code_add_link(struct psection *where, struct psection *to,
310 to->refcnt++; // this will be checked elsewhere
311 if (where->last && where->last->child == NULL) {
312 where->last->child = to;
315 n = malloc(sizeof(*n));
322 where->last->next = n;
330 Now we need a lookup table to be able to find sections by name.
331 Something that provides an `n*log(N)` search time is probably
332 justified, but for now I want a minimal stand-alone program so a
333 linked list managed by insertion-sort will do. As a comparison
334 function it is easiest to sort based on length before content. So
335 sections won't be in standard lexical order, but that isn't important.
337 If we cannot find a section, we simply want to create it. This allows
338 sections and references to be created in any order. Sections with
339 no references or no content will cause a warning eventually.
341 #### internal functions
343 static int text_cmp(struct text a, struct text b)
346 return a.len - b.len;
347 return strncmp(a.txt, b.txt, a.len);
350 static struct psection *section_find(struct psection **list, struct text name)
352 struct psection *new;
354 int cmp = text_cmp((*list)->section, name);
359 list = (struct psection **)&((*list)->next);
361 /* Add this section */
362 new = malloc(sizeof(*new));
373 ## Parsing the _markdown_
375 Parsing markdown is fairly easy, though there are complications.
377 The document is divided into "paragraphs" which are mostly separated by blank
378 lines (which may contain white space). The first few characters of
379 the first line of a paragraph determine the type of paragraph. For
380 our purposes we are only interested in list paragraphs, code
381 paragraphs, section headings, and everything else. Section headings
382 are single-line paragraphs and so do not require a preceding or
383 following blank line.
385 Section headings start with 1 or more hash characters (__#__). List
386 paragraphs start with hyphen, asterisk, plus, or digits followed by a
387 period. Code paragraphs aren't quite so easy.
389 The "standard" code paragraph starts with 4 or more spaces, or a tab.
390 However if the previous paragraph was a list paragraph, then those
391 spaces indicate another paragraph in the same list item, and 8 or
392 more spaces are required. Unless a nested list is in effect, in
393 which case 12 or more are need. Unfortunately not all _markdown_
394 parsers agree on nested lists.
396 Two alternate styles for marking code are in active use. "Github" uses
397 three backticks(_`` ``` ``_), while "pandoc" uses three or more tildes
398 (_~~~_). In these cases the code should not be indented.
400 Trying to please everyone as much as possible, this parser will handle
401 everything except for code inside lists.
403 So an indented (4+) paragraph after a list paragraph is always a list
404 paragraph, otherwise it is a code paragraph. A paragraph that starts
405 with three backticks or three tildes is code which continues until a
406 matching string of backticks or tildes.
410 While walking the document looking for various markers we will *not*
411 use the `struct text` introduced earlier as advancing that requires
412 updating both start and length which feels clumsy. Instead we will
413 carry `pos` and `end` pointers, only the first of which needs to
416 So to start, we need to skip various parts of the document. `lws`
417 stands for "Linear White Space" and is a term that comes from the
418 Email RFCs (e.g. RFC822). `line` and `para` are self explanatory.
419 Note that `skip_para` needs to update the current line number.
420 `skip_line` doesn't but every caller should.
422 #### internal functions
424 static char *skip_lws(char *pos, char *end)
426 while (pos < end && (*pos == ' ' || *pos == '\t'))
431 static char *skip_line(char *pos, char *end)
433 while (pos < end && *pos != '\n')
440 static char *skip_para(char *pos, char *end, int *line_no)
442 /* Might return a pointer to a blank line, as only
443 * one trailing blank line is skipped
446 pos = skip_line(pos, end);
452 *(pos = skip_lws(pos, end)) != '\n') {
453 pos = skip_line(pos, end);
456 if (pos < end && *pos == '\n') {
463 ### Recognising things
465 Recognising a section header is trivial and doesn't require a
466 function. However we need to extract the content of a section header
467 as a `struct text` for passing to `section_find`.
468 Recognising the start of a new list is fairly easy. Recognising the
469 start (and end) of code is a little messy so we provide a function for
470 matching the first few characters, which has a special case for "4
473 #### internal includes
478 #### internal functions
480 static struct text take_header(char *pos, char *end)
484 while (pos < end && *pos == '#')
486 while (pos < end && *pos == ' ')
489 while (pos < end && *pos != '\n')
491 while (pos > section.txt &&
492 (pos[-1] == '#' || pos[-1] == ' '))
494 section.len = pos - section.txt;
498 static int is_list(char *pos, char *end)
500 if (strchr("-*+", *pos))
503 while (pos < end && isdigit(*pos))
505 if (pos < end && *pos == '.')
511 static int matches(char *start, char *pos, char *end)
514 return matches("\t", pos, end) ||
515 matches(" ", pos, end);
516 return (pos + strlen(start) < end &&
517 strncmp(pos, start, strlen(start)) == 0);
520 ### Extracting the code
522 Now that we can skip paragraphs and recognise what type each paragraph
523 is, it is time to parse the file and extract the code. We'll do this
524 in two parts, first we look at what to do with some code once we
525 find it, and then how to actually find it.
527 When we have some code, we know where it is, what the end marker
528 should look like, and which section it is in.
530 There are two sorts of end markers: the presence of a particular
531 string, or the absence of an indent. We will use a string to
532 represent a presence, and a `NULL` to represent the absence.
534 While looking at code we don't think about paragraphs are all - just
535 look for a line that starts with the right thing.
536 Every line that is still code then needs to be examined to see if it
537 is a section reference.
539 When a section reference is found, all preceding code (if any) must be
540 added to the current section, then the reference is added.
542 When we do find the end of the code, all text that we have found but
543 not processed needs to be saved too.
545 When adding a reference we need to set the `indent`. This is the
546 number of spaces (counting 8 for tabs) after the natural indent of the
547 code (which is a tab or 4 spaces). We use a separate function `count_spaces`
550 #### internal functions
552 static int count_space(char *sol, char *p)
566 static char *take_code(char *pos, char *end, char *marker,
567 struct psection **table, struct text section,
571 int line_no = *line_nop;
572 int start_line = line_no;
573 struct psection *sect;
575 sect = section_find(table, section);
581 if (marker && matches(marker, pos, end))
584 (skip_lws(pos, end))[0] != '\n' &&
585 !matches(NULL, pos, end))
586 /* Paragraph not indented */
589 /* Still in code - check for reference */
594 else if (strcmp(sol, " ") == 0)
597 t = skip_lws(sol, end);
598 if (t[0] != '#' || t[1] != '#') {
599 /* Just regular code here */
600 pos = skip_line(sol, end);
608 txt.len = pos - start;
609 code_add_text(sect, txt, start_line,
612 ref = take_header(t, end);
614 struct psection *refsec = section_find(table, ref);
615 code_add_link(sect, refsec, count_space(sol, t));
617 pos = skip_line(t, end);
620 start_line = line_no;
625 txt.len = pos - start;
626 code_add_text(sect, txt, start_line,
630 pos = skip_line(pos, end);
639 It is when looking for the code that we actually use the paragraph
640 structure. We need to recognise section headings so we can record the
641 name, list paragraphs so we can ignore indented follow-on paragraphs,
642 and the three different markings for code.
644 #### internal functions
646 static struct psection *code_find(char *pos, char *end)
648 struct psection *table = NULL;
651 struct text section = {0};
655 section = take_header(pos, end);
657 pos = skip_line(pos, end);
659 } else if (is_list(pos, end)) {
661 pos = skip_para(pos, end, &line_no);
662 } else if (!in_list && matches(NULL, pos, end)) {
663 pos = take_code(pos, end, NULL, &table,
665 } else if (matches("```", pos, end)) {
667 pos = skip_line(pos, end);
669 pos = take_code(pos, end, "```", &table,
671 } else if (matches("~~~", pos, end)) {
673 pos = skip_line(pos, end);
675 pos = take_code(pos, end, "~~~", &table,
680 pos = skip_para(pos, end, &line_no);
686 ### Returning the code
688 Having found all the code blocks and gathered them into a list of
689 section, we are now ready to return them to the caller. This is where
690 to perform consistency checks, like at most one reference and at least
691 one definition for each section.
693 All the sections with no references are returned in a list for the
694 caller to consider. The are linearized first so that the substructure
695 is completely hidden -- except for the small amount of structure
696 displayed in the line numbers.
698 To return errors, we have the caller pass a function which takes an
699 error message - a `code_err_fn`.
703 typedef void (*code_err_fn)(char *msg);
705 #### internal functions
706 struct section *code_extract(char *pos, char *end, code_err_fn error)
708 struct psection *table;
709 struct section *result = NULL;
710 struct section *tofree = NULL;
712 table = code_find(pos, end);
715 struct psection *t = (struct psection*)table->next;
716 if (table->last == NULL) {
719 "Section \"%.*s\" is referenced but not declared",
720 table->section.len, table->section.txt);
724 if (table->refcnt == 0) {
725 /* Root-section, return it */
726 table->next = result;
728 code_linearize(result->code);
730 table->next = tofree;
732 if (table->refcnt > 1) {
735 "Section \"%.*s\" referenced multiple times (%d).",
736 table->section.len, table->section.txt,
745 struct section *t = tofree->next;
752 ##### exported functions
754 struct section *code_extract(char *pos, char *end, code_err_fn error);
759 Now that we can extract code from a document and link it all together
760 it is time to do something with that code. Firstly we need to print
763 ### Printing the Code
765 Printing is mostly straight forward - we just walk the list and print
766 the code sections, adding whatever indent is required for each line.
767 However there is a complication (isn't there always)?
769 For code that was recognised because the paragraph was indented, we
770 need to strip that indent first. For other code, we don't.
772 The approach taken here is simple, though it could arguably be wrong
773 in some unlikely cases. So it might need to be fixed later.
775 If the first line of a code block is indented, then either one tab or
776 4 spaces are striped from every non-blank line.
778 This could go wrong if the first line of a code block marked by
779 _`` ``` ``_ is indented. To overcome this we would need to
780 record some extra state in each `code_node`. For now we won't bother.
782 The indents we insert will all be spaces. This might not work well
785 ##### internal functions
787 void code_node_print(FILE *out, struct code_node *node,
790 for (; node; node = node->next) {
791 char *c = node->code.txt;
792 int len = node->code.len;
797 fprintf(out, "#line %d \"%s\"\n",
798 node->line_no, fname);
800 fprintf(out, "%*s", node->indent, "");
801 if (node->needs_strip) {
802 if (*c == '\t' && len > 1) {
805 } else if (strncmp(c, " ", 4) == 0 && len > 4) {
814 } while (len && c[-1] != '\n');
819 ###### exported functions
820 void code_node_print(FILE *out, struct code_node *node, char *fname);
822 ### Bringing it all together
824 We are just about ready for the `main` function of the tool which will
825 extract all this lovely code and compile it. Just one helper is still
828 #### Handling filenames
830 Section names are stored in `struct text` which is not `nul`
831 terminated. Filenames passed to `open` need to be null terminated.
832 So we need to convert one to the other, and strip the leading `File:`
833 of while we are at it.
835 ##### client functions
837 static void copy_fname(char *name, int space, struct text t)
842 if (len < 5 || strncmp(sec, "File:", 5) != 0)
846 while (len && sec[0] == ' ') {
852 strncpy(name, sec, len);
858 And now we take a single file name, extract the code, and if there are
859 no error we write out a file for each appropriate code section. And
863 ##### client includes
867 #include <sys/mman.h>
870 ##### client functions
873 static void pr_err(char *msg)
876 fprintf(stderr, "%s\n", msg);
879 static char *strnchr(char *haystack, int len, char needle)
881 while (len > 0 && *haystack && *haystack != needle) {
885 return len > 0 && *haystack == needle ? haystack : NULL;
888 int main(int argc, char *argv[])
893 struct section *table, *s, *prev;
897 fprintf(stderr, "Usage: mdcode file.mdc\n");
900 fd = open(argv[1], O_RDONLY);
902 fprintf(stderr, "mdcode: cannot open %s: %s\n",
903 argv[1], strerror(errno));
906 len = lseek(fd, 0, 2);
907 file = mmap(NULL, len, PROT_READ, MAP_SHARED, fd, 0);
908 table = code_extract(file, file+len, pr_err);
911 (code_free(s->code), prev = s, s = s->next, free(prev))) {
914 char *spc = strnchr(s->section.txt, s->section.len, ' ');
916 if (spc > s->section.txt && spc[-1] == ':' &&
917 strncmp(s->section.txt, "File: ", 6) != 0)
918 /* Ignore this section */
920 if (strncmp(s->section.txt, "File: ", 6) != 0) {
921 fprintf(stderr, "Code in unreferenced section that is not ignored or a file name: %.*s\n",
922 s->section.len, s->section.txt);
926 copy_fname(fname, sizeof(fname), s->section);
928 fprintf(stderr, "Missing file name at:%.*s\n",
929 s->section.len, s->section.txt);
933 fl = fopen(fname, "w");
935 fprintf(stderr, "Cannot create %s: %s\n",
936 fname, strerror(errno));
940 code_node_print(fl, s->code, argv[1]);