Merge branch 'release/6.2.3'

.astylerc

@@ -7,7 +7,7 @@
 
 
 # Indents
---indent=tab=4
+--indent=force-tab=4
 
 
 # Switch statements

CMakeLists.txt

@@ -8,10 +8,10 @@ cmake_minimum_required (VERSION 2.6)
 set (My_Project_Title "MultiMarkdown")
 set (My_Project_Description "Lightweight markup processor to produce HTML, LaTeX, and more.")
 set (My_Project_Author "Fletcher T. Penney")
-set (My_Project_Revised_Date "2017-10-13")
+set (My_Project_Revised_Date "2017-11-20")
 set (My_Project_Version_Major 6)
 set (My_Project_Version_Minor 2)
-set (My_Project_Version_Patch 2)
+set (My_Project_Version_Patch 3)
 
 set (My_Project_Version "${My_Project_Version_Major}.${My_Project_Version_Minor}.${My_Project_Version_Patch}")
 
@@ -183,6 +183,7 @@ set(src_files
 	Sources/libMultiMarkdown/critic_markup.c
 	Sources/libMultiMarkdown/d_string.c
 	Sources/libMultiMarkdown/epub.c
+	Sources/libMultiMarkdown/file.c
 	Sources/libMultiMarkdown/fodt.c
 	Sources/libMultiMarkdown/html.c
 	Sources/libMultiMarkdown/latex.c
@@ -214,6 +215,7 @@ set(header_files
 	Sources/libMultiMarkdown/critic_markup.h
 	Sources/libMultiMarkdown/include/d_string.h
 	Sources/libMultiMarkdown/epub.h
+	Sources/libMultiMarkdown/file.h
 	Sources/libMultiMarkdown/fodt.h
 	Sources/libMultiMarkdown/html.h
 	Sources/libMultiMarkdown/latex.h

DevelopmentNotes/DevelopmentNotes.fodt

@@ -276,7 +276,7 @@ office:mimetype="application/vnd.oasis.opendocument.text">
 <office:meta>
 	<dc:title>MultiMarkdown v6 Development Notes</dc:title>
 	<dc:creator>Fletcher T. Penney</dc:creator>
-	<meta:user-defined meta:name="date">2017-10-13</meta:user-defined>
+	<meta:user-defined meta:name="date">2017-11-20</meta:user-defined>
 	<meta:user-defined meta:name="uuid">dd2d8e76-dc2d-416d-9acd-5395d20871c2</meta:user-defined>
 </office:meta>
 <office:body>
@@ -531,7 +531,7 @@ added up and slowed down performance.</text:p>
 
 <text:p text:style-name="Standard">After reading for a bit, I ended up coming up with an approach that uses
 larger chunks of memory. I allocate pools of of memory in large slabs for
-smaller &#8220;objects&#8221;&quot;. For example, I allocate memory for 1024 tokens at a
+smaller &quot;objects. For example, I allocate memory for 1024 tokens at a
 single time, and then dole that memory out as needed. When the slab is empty,
 a new one is allocated. This dramatically improved performance.</text:p>
 
@@ -566,7 +566,7 @@ measurable difference.</text:p>
 <text:p text:style-name="Standard">I experimented with different approaches to creating the output after parsing.
 I tried printing directly to <text:span text:style-name="Source_20_Text">stdout</text:span>, and even played with different
 buffering settings. None of those seemed to work well, and all were slower
-than using the <text:span text:style-name="Source_20_Text">d_string</text:span> approach (formerly call <text:span text:style-name="Source_20_Text">GString</text:span> in MMD 5).</text:p>
+than using the <text:span text:style-name="Source_20_Text">d_string</text:span> approach (formerly called <text:span text:style-name="Source_20_Text">GString</text:span> in MMD 5).</text:p>
 
 <text:h text:outline-level="4"><text:bookmark text:name="fastsearches"/>Fast Searches </text:h>
 
@@ -684,10 +684,10 @@ application with every release.</text:p>
 
 <text:h text:outline-level="4"><text:bookmark text:name="fuzztesting"/>Fuzz Testing </text:h>
 
-<text:p text:style-name="Standard">I was not familiar with the concept of <text:a xlink:type="simple" xlink:href="#fuzztesting">Fuzz Testing</text:a>
-(https://en.wikipedia.org/wiki/Fuzzing) until a user mentioned something about
-it to me a year or two ago. I had never used it before, but it seemed like a
-good idea. I implement it in two ways.</text:p>
+<text:p text:style-name="Standard">I was not familiar with the concept of
+<text:a xlink:type="simple" xlink:href="https://en.wikipedia.org/wiki/Fuzzing">Fuzz Testing</text:a> until a user mentioned
+something about it to me a year or two ago. I had never used it before, but
+it seemed like a good idea. I implemented it in two ways.</text:p>
 
 <text:p text:style-name="Standard">The first is that I created a simplified version of the line parser that
 simply accepts various combinations of line type identifiers to see if they
@@ -702,13 +702,13 @@ several combinations of lines that did not pass.</text:p>
 <text:p text:style-name="Standard"><text:span text:style-name="MMD-Bold">NOTE</text:span>: This does not verify accurate parsing, simply that the parser does
 not crash by an unacceptable combination of lines.</text:p>
 
-<text:p text:style-name="Standard">The second form of fuzz testing I have started using more recently. This is
-using the <text:a xlink:type="simple" xlink:href="http://lcamtuf.coredump.cx/afl/">American fuzzy lop</text:a> program to try
-to find text input that crashes MMD. This works by taking sample input (e.g.
-files from the test suite), modifying them slightly, and trying the modified
+<text:p text:style-name="Standard">The second form of fuzz testing I started using later. This is using the
+<text:a xlink:type="simple" xlink:href="http://lcamtuf.coredump.cx/afl/">American fuzzy lop</text:a> program to try to find
+text input that crashes MMD. This works by taking sample input (e.g. files
+from the test suite), modifying them slightly, and trying the modified
 versions. Do this over and over and over, and some interesting edge cases are
 sometimes identified. I have found some interesting edge cases this way.
-Definitely a very useful tool!</text:p>
+Definitely a useful tool!</text:p>
 
 <text:h text:outline-level="4"><text:bookmark text:name="unittesting"/>Unit Testing </text:h>
 
@@ -762,6 +762,67 @@ TextBundle/TextPack, OpenDocument, etc.</text:p></text:list-item>
 <text:h text:outline-level="3"><text:bookmark text:name="changelog"/>Changelog </text:h>
 
 <text:list text:style-name="L1">
+<text:list-item>
+<text:p text:style-name="Standard">2017&#8211;11&#8211;20 - v 6.2.3:</text:p>
+
+<text:list text:style-name="L1">
+<text:list-item>
+<text:p text:style-name="P1">
+CHANGED: Fix typos</text:p></text:list-item>
+
+<text:list-item>
+<text:p text:style-name="P1">
+CHANGED: Update superscript/subscript algorithm to allow leading instances</text:p></text:list-item>
+
+<text:list-item>
+<text:p text:style-name="P1">
+FIXED: Fix bug with multiple footnotes in single paragraph when exporting to LaTeX</text:p></text:list-item>
+
+<text:list-item>
+<text:p text:style-name="P1">
+FIXED: Fix potential NULL pointer dereference</text:p></text:list-item>
+
+<text:list-item>
+<text:p text:style-name="P1">
+FIXED: Fix potential bug</text:p></text:list-item>
+
+<text:list-item>
+<text:p text:style-name="P1">
+FIXED: Prevent pointer overflow</text:p></text:list-item>
+
+<text:list-item>
+<text:p text:style-name="P1">
+FIXED: Strip UTF-8 BOM from main files, not just transcluded files</text:p></text:list-item>
+
+<text:list-item>
+<text:p text:style-name="P1">
+UPDATED: Add HTML comment test cases to further demonstrate</text:p></text:list-item>
+
+<text:list-item>
+<text:p text:style-name="P1">
+UPDATED: Adjust libMultiMarkdown.h so it does not recursively include other files</text:p></text:list-item>
+
+<text:list-item>
+<text:p text:style-name="P1">
+UPDATED: Fix issue with AStyle indent settings</text:p></text:list-item>
+
+<text:list-item>
+<text:p text:style-name="P1">
+UPDATED: Refactor file utilities into file.c/h</text:p></text:list-item>
+
+<text:list-item>
+<text:p text:style-name="P1">
+UPDATED: Silence Xcode static analyzer false positives</text:p></text:list-item>
+
+<text:list-item>
+<text:p text:style-name="P1">
+UPDATED: Silence analyzer warnings</text:p></text:list-item>
+
+<text:list-item>
+<text:p text:style-name="Standard">UPDATED: Update function name in swift file</text:p></text:list-item>
+
+</text:list></text:list-item>
+
 <text:list-item>
 <text:p text:style-name="Standard">2017&#8211;10&#8211;13 - v 6.2.2.:</text:p>
 

DevelopmentNotes/DevelopmentNotes.html

@@ -4,7 +4,7 @@
 	<meta charset="utf-8"/>
 	<title>MultiMarkdown v6 Development Notes</title>
 	<meta name="author" content="Fletcher T. Penney"/>
-	<meta name="date" content="2017-10-13"/>
+	<meta name="date" content="2017-11-20"/>
 	<meta name="uuid" content="dd2d8e76-dc2d-416d-9acd-5395d20871c2"/>
 </head>
 <body>
@@ -209,7 +209,7 @@ <h4 id="memoryallocation">Memory Allocation </h4>
 
 <p>After reading for a bit, I ended up coming up with an approach that uses
 larger chunks of memory. I allocate pools of of memory in large slabs for
-smaller &#8220;objects&#8221;&quot;. For example, I allocate memory for 1024 tokens at a
+smaller &quot;objects. For example, I allocate memory for 1024 tokens at a
 single time, and then dole that memory out as needed. When the slab is empty,
 a new one is allocated. This dramatically improved performance.</p>
 
@@ -244,7 +244,7 @@ <h4 id="outputbuffering">Output Buffering </h4>
 <p>I experimented with different approaches to creating the output after parsing.
 I tried printing directly to <code>stdout</code>, and even played with different
 buffering settings. None of those seemed to work well, and all were slower
-than using the <code>d_string</code> approach (formerly call <code>GString</code> in MMD 5).</p>
+than using the <code>d_string</code> approach (formerly called <code>GString</code> in MMD 5).</p>
 
 <h4 id="fastsearches">Fast Searches </h4>
 
@@ -362,10 +362,10 @@ <h4 id="testsuite">Test Suite </h4>
 
 <h4 id="fuzztesting">Fuzz Testing </h4>
 
-<p>I was not familiar with the concept of <a href="#fuzztesting">Fuzz Testing</a>
-(https://en.wikipedia.org/wiki/Fuzzing) until a user mentioned something about
-it to me a year or two ago. I had never used it before, but it seemed like a
-good idea. I implement it in two ways.</p>
+<p>I was not familiar with the concept of
+<a href="https://en.wikipedia.org/wiki/Fuzzing">Fuzz Testing</a> until a user mentioned
+something about it to me a year or two ago. I had never used it before, but
+it seemed like a good idea. I implemented it in two ways.</p>
 
 <p>The first is that I created a simplified version of the line parser that
 simply accepts various combinations of line type identifiers to see if they
@@ -380,13 +380,13 @@ <h4 id="fuzztesting">Fuzz Testing </h4>
 <p><strong>NOTE</strong>: This does not verify accurate parsing, simply that the parser does
 not crash by an unacceptable combination of lines.</p>
 
-<p>The second form of fuzz testing I have started using more recently. This is
-using the <a href="http://lcamtuf.coredump.cx/afl/">American fuzzy lop</a> program to try
-to find text input that crashes <abbr title="MultiMarkdown">MMD</abbr>. This works by taking sample input (e.g.
-files from the test suite), modifying them slightly, and trying the modified
+<p>The second form of fuzz testing I started using later. This is using the
+<a href="http://lcamtuf.coredump.cx/afl/">American fuzzy lop</a> program to try to find
+text input that crashes <abbr title="MultiMarkdown">MMD</abbr>. This works by taking sample input (e.g. files
+from the test suite), modifying them slightly, and trying the modified
 versions. Do this over and over and over, and some interesting edge cases are
 sometimes identified. I have found some interesting edge cases this way.
-Definitely a very useful tool!</p>
+Definitely a useful tool!</p>
 
 <h4 id="unittesting">Unit Testing </h4>
 
@@ -432,6 +432,24 @@ <h3 id="dependencieslibraries">Dependencies/Libraries </h3>
 <h3 id="changelog">Changelog </h3>
 
 <ul>
+<li><p>2017&#8211;11&#8211;20 - v 6.2.3:</p>
+
+<ul>
+<li>CHANGED: Fix typos</li>
+<li>CHANGED: Update superscript/subscript algorithm to allow leading instances</li>
+<li>FIXED: Fix bug with multiple footnotes in single paragraph when exporting to LaTeX</li>
+<li>FIXED: Fix potential NULL pointer dereference</li>
+<li>FIXED: Fix potential bug</li>
+<li>FIXED: Prevent pointer overflow</li>
+<li>FIXED: Strip UTF-8 BOM from main files, not just transcluded files</li>
+<li>UPDATED: Add HTML comment test cases to further demonstrate</li>
+<li>UPDATED: Adjust libMultiMarkdown.h so it does not recursively include other files</li>
+<li>UPDATED: Fix issue with AStyle indent settings</li>
+<li>UPDATED: Refactor file utilities into file.c/h</li>
+<li>UPDATED: Silence Xcode static analyzer false positives</li>
+<li>UPDATED: Silence analyzer warnings</li>
+<li>UPDATED: Update function name in swift file</li>
+</ul></li>
 <li><p>2017&#8211;10&#8211;13 - v 6.2.2.:</p>
 
 <ul>

DevelopmentNotes/DevelopmentNotes.txt

@@ -1,6 +1,6 @@
 Title:	MultiMarkdown v6 Development Notes
 Author:	Fletcher T. Penney
-Date: 2017-10-13  
+Date: 2017-11-20  
 LaTeX Config:	tufte-handout
 Base Header Level:	3
 uuid: dd2d8e76-dc2d-416d-9acd-5395d20871c2
@@ -217,7 +217,7 @@ added up and slowed down performance.
 
 After reading for a bit, I ended up coming up with an approach that uses
 larger chunks of memory.  I allocate pools of of memory in large slabs for
-smaller "objects"".  For example, I allocate memory for 1024 tokens at a
+smaller "objects.  For example, I allocate memory for 1024 tokens at a
 single time, and then dole that memory out as needed.  When the slab is empty,
 a new one is allocated.  This dramatically improved performance.
 
@@ -254,7 +254,7 @@ measurable difference.
 I experimented with different approaches to creating the output after parsing.
 I tried printing directly to `stdout`, and even played with different
 buffering settings.  None of those seemed to work well, and all were slower
-than using the `d_string` approach (formerly call `GString` in MMD 5).
+than using the `d_string` approach (formerly called `GString` in MMD 5).
 
 
 ## Fast Searches ##
@@ -383,10 +383,10 @@ application with every release.
 
 ## Fuzz Testing ##
 
-I was not familiar with the concept of [Fuzz Testing]
-(https://en.wikipedia.org/wiki/Fuzzing) until a user mentioned something about
-it to me a year or two ago.  I had never used it before, but it seemed like a
-good idea.  I implement it in two ways.
+I was not familiar with the concept of
+[Fuzz Testing](https://en.wikipedia.org/wiki/Fuzzing) until a user mentioned
+something about it to me a year or two ago.  I had never used it before, but
+it seemed like a good idea.  I implemented it in two ways.
 
 The first is that I created a simplified version of the line parser that
 simply accepts various combinations of line type identifiers to see if they
@@ -401,13 +401,13 @@ several combinations of lines that did not pass.
 **NOTE**: This does not verify accurate parsing, simply that the parser does
 not crash by an unacceptable combination of lines.
 
-The second form of fuzz testing I have started using more recently.  This is
-using the [American fuzzy lop](http://lcamtuf.coredump.cx/afl/) program to try
-to find text input that crashes MMD.  This works by taking sample input (e.g.
-files from the test suite), modifying them slightly, and trying the modified
+The second form of fuzz testing I started using later.  This is using the
+[American fuzzy lop](http://lcamtuf.coredump.cx/afl/) program to try to find
+text input that crashes MMD.  This works by taking sample input (e.g. files
+from the test suite), modifying them slightly, and trying the modified
 versions.  Do this over and over and over, and some interesting edge cases are
 sometimes identified.  I have found some interesting edge cases this way.
-Definitely a very useful tool!
+Definitely a useful tool!
 
 
 ## Unit Testing ##
@@ -471,6 +471,24 @@ TextBundle/TextPack, OpenDocument, etc.
 
 # Changelog #
 
+* 2017-11-20 - v 6.2.3:
+
+	*    CHANGED: Fix typos
+	*    CHANGED: Update superscript/subscript algorithm to allow leading instances
+	*    FIXED: Fix bug with multiple footnotes in single paragraph when exporting to LaTeX
+	*    FIXED: Fix potential NULL pointer dereference
+	*    FIXED: Fix potential bug
+	*    FIXED: Prevent pointer overflow
+	*    FIXED: Strip UTF-8 BOM from main files, not just transcluded files
+	*    UPDATED: Add HTML comment test cases to further demonstrate
+	*    UPDATED: Adjust libMultiMarkdown.h so it does not recursively include other files
+	*    UPDATED: Fix issue with AStyle indent settings
+	*    UPDATED: Refactor file utilities into file.c/h
+	*    UPDATED: Silence Xcode static analyzer false positives
+	*    UPDATED: Silence analyzer warnings
+	*    UPDATED: Update function name in swift file
+
+
 * 2017-10-13 - v 6.2.2.:
 
 	*    ADDED: Add support for tables without header; test for table with multiple header rows

Makefile

@@ -128,4 +128,4 @@ CHANGELOG:
 # Use astyle
 .PHONY : astyle
 astyle:
-	astyle --options=.astylerc "Sources/libMultiMarkdown/*.c" "Sources/multimarkdown/*.c" "Sources/libMultiMarkdown/*.h" 
+	astyle --options=.astylerc "Sources/libMultiMarkdown/*.c" "Sources/multimarkdown/*.c" "Sources/libMultiMarkdown/*.h"  "Sources/libMultiMarkdown/include/*.h" 

README.md

@@ -4,9 +4,9 @@
 | ---------- | ------------------------- |  
 | Title:     | MultiMarkdown        |  
 | Author:    | Fletcher T. Penney       |  
-| Date:      | 2017-10-13 |  
+| Date:      | 2017-11-20 |  
 | Copyright: | Copyright © 2016 - 2017 Fletcher T. Penney.    |  
-| Version:   | 6.2.2      |  
+| Version:   | 6.2.3      |  
 
 master branch: [![Build Status](https://travis-ci.org/fletcher/MultiMarkdown-6.svg?branch=master)](https://travis-ci.org/fletcher/MultiMarkdown-6)  
 develop branch: [![Build Status](https://travis-ci.org/fletcher/MultiMarkdown-6.svg?branch=develop)](https://travis-ci.org/fletcher/MultiMarkdown-6)