My first compiler bug: work around or redesign?

Hello,

I happen to have encountered my very first compiler bug, or at least
something that claims to be in the following message:

+===========================GNAT BUG DETECTED==============================+
| 4.6.2 20111026 (release) -=> GNAT AUX [FreeBSD64] (x86_64-aux-freebsd9.0) GCC error:|
| in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4134 |
| Error detected at dressup-parsers-markdown.adb:184:4 [dressup-parsers-markdown.adb:1651:7 [markdown.adb:32:4]]|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html. |
| Use a subject line meaningful to you and us to track the bug. |
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+================================================= =========================+

So my first question is, would anyone be kind enough to try and
reproduce that bug? The files involved are available individually at
http://fossil.instinctive.eu/dressup...54531f8dcf7117
or as a tarball at
http://fossil.instinctive.eu/dressup...b886701222c342

The reason is that I'm using gnat AUX, derived from gcc 4.6.2, so it's
both unofficial and old (IIRC tasking in FreeBSD 9 is preventing the
next one from being available). It's difficult to create a new building
environment, so I would like to be sure it's really a bug before setting
out to make a minimalistic test case and reporting it.

I guess the problem somehow involves generics:
Dressup.Parsers is a generic package; so Dressup.Parsers.Markdown is
generic too, despite adding no further formal parameter.
markdown.adb:32:4 is the instantiation of Dressup.Parsers.Markdown (off
an instance of Dressup.Parsers instantiated on the line before).
dressup-parsers-markdown.adb:1651:7 is an instantiation of a subprogram
whose specification is at dressup-parsers-markdown.adb:184:4.

Could the issue be caused by having a generic instance inside a generic
instance inside a generic instance? Or is gnat supposed to handle well
such a level of nesting?



All this led me to question my approach and design and programming
practices, so that if I have to rewrite something to work around the
compiler bug, I can rewrite better.

So my first "best practices" question is about using generic subprograms
confined inside a package body. Here is a brutally-simplified version of
what is reported in the compiler bug message:

package Stuff is
procedure Ordered_List (<some set of parameters);
procedure Unordered_List (<the same set of parameters);
end Stuff;

package body Stuff is
generic
with Prefix (Line : String) return Natural;
procedure Generic_List (<same set of parameters as previously>);

function Ordered_Prefix (Line : String) return Natural;
function Unordered_Prefix (Line : String) return Natural;

-- subprogram bodies here

procedure Ordered_List_Instance is new Generic_List (Ordered_Prefix);

procedure Ordered_List (<same set of parameters as in the spec>)
renames Oredered_List_Instance;

procedure Unordered_List_Instance is new Generic_List (Unordered_Prefix);

procedure Unordered_List (<same set of parameters as in the spec>)
renames Unordered_List_Instance;

end Stuff;

The rationale here is that Ordered_List and Unordered_List are meant to
be completely independent, so they are presented in the specification as
being completely unrelated.

However, at implementation level, it turns out that they are very
similar: only the prefix recognition change, and further processing is
perfectly identical. So instead of cut-and-pasting code, I would write a
generic that handles all the common aspects, using a formal function for
the prefix part.

Is there something wrong with that approach?
Are there some caveat that I missed?
Are there advantages in avoiding the generics in that situation, for
example using a non-generic common function that takes an
access-to-subprogram extra parameter?

And as a tangential question, could anyone explain me why the "renames"
are required? How come a generic instantiation cannot provide a body for
a publicly-specified subprogram?




And the last part of the message here is about the general design of the
library. I have ended up using a lot of generics and access to
subprograms, but no tagged types (actually some types are tagged, but
only for future expansions, none of the code written here use any tagged
type feature).

I would understand anyone skipping that part of the discussion, but any
constructive comment will be appreciated (though not necessarily acted
upon).

The initial problem I was set out to solve was converting markdown into
HTML, but with enough modularity so that I can convert markdown into PDF
without changing the "markdown" part (that I call "parser", I hope I got
the word right), or convert creole into HTML without changing the "HTML"
part (that I call "renderer"). And as an extra requirement, I want
features of a parser to be easily and individually turned off (e.g.
removing the raw HTML inclusion in markdown for untrusted sources, or
removing the "wiki link" feature of creole where it is used outside of a
wiki).

In my previous iteration of markdown-to-HTML code (in C), I found that
a usable description of a renderer is a bunch of callbacks that operate
on the same shared state.

So for my Ada library, I decided to describe a renderer as a state
object and a set of accesses to procedure. The idea being that each
procedure renders a particular element (e.g. an ordered list, and the
callback for HTML would output "<ol>", the contents and "</ol>").
Language elements without a renderer callback are considered as
disabled.

That way, the renderer does not need to know anything about the parser,
and the parser only handles callbacks and an opaque, so it is also
independent from any particular renderer. Only the client has to care
about both the particular renderer and the particular parser in use.

I went for access to subprogram rather than a tagged type for element
renderers to ensure that all callbacks do share the same state, since in
the tagged type version each element renderer object would have its own
state (presumably referring to some shared state like the output
string or stream), there would then be no compile-time guarantee that
all renderer elements indeed belong to the same renderer. A client who
mistakenly mixes callbacks and ends up with a set of callbacks referring
to one state and another set referring to another, would have no
indication of their mistake before seeing garbage at run time.

Moreover, using dynamic dispatching of tagged type instead of access to
subprogram would mean storing somewhere object of a class-wide type,
i.e. indefinite. So it would mean extra complications like holders
objects, which make the program harder to read and to understand.
These drawbacks without benefit (unless I'm missing something) was
enough for me to rule out the option.

I then proceeded to write the (X)HTML renderer. While thinking about the
implementation, I realized that I would only need to append string
fragments. So I wrote it as a generic package, with an Accumulator
formal type and an Append procedure. Again it looked much simpler than
using an approach based on tagged type (and interfaces), but this time
en client side rather than on library side: Unbounded_String are bundled
with an Append procedure that fits perfectly, streams might be useful
out of box if String'Write can be used directly for Append. With a
interfaces, the client would have to maintain a wrapper around
Unbounded_String or streams or whatever accumulator they re-use, and it
feels to me like unnecessary clutter. Moreover it seems possible and
relatively simple to instance the generic markdown renderer with an
interface type, while the advantages of the generic version seem out of
reach of a version based on interfaces.

With this representation of renderers, I started shaping the parser with
a generic ancestor package Dressup.Parsers, that only defines the type
Element_Renderer used for the callbacks.

The extra genericity and accesses to subprograms of
Dressup.Parsers.Lexers follows the same rationale as for renderers.

I think that covers all the debatable choices, though if you feel like
discussion another one, feel free to do so.



Thanks a lot in advance for your helpful insights,
Natasha

Natasha Kerensikova <lithiumcat@gmail.com> writes:

> Hello,
>
> I happen to have encountered my very first compiler bug, or at least
> something that claims to be in the following message:
>
> +===========================GNAT BUG DETECTED==============================+
> | 4.6.2 20111026 (release) -=> GNAT AUX [FreeBSD64] (x86_64-aux-freebsd9.0) GCC error:|
> | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4134 |
> | Error detected at dressup-parsers-markdown.adb:184:4 [dressup-parsers-markdown.adb:1651:7 [markdown.adb:32:4]]|

This seems similar to http://gcc.gnu.org/PR43806, the workaround for
which is not to use -gnatE. Were you compiling with -gnatE?

> So my first question is, would anyone be kind enough to try and
> reproduce that bug? The files involved are available individually at
> http://fossil.instinctive.eu/dressup...54531f8dcf7117
> or as a tarball at
> http://fossil.instinctive.eu/dressup...b886701222c342

I'll try later if I find the time :/

--
Ludovic Brenta.

On 03/23/2012 09:29 AM, Natasha Kerensikova wrote:
>
> However, at implementation level, it turns out that they are very
> similar: only the prefix recognition change, and further processing is
> perfectly identical. So instead of cut-and-pasting code, I would write a
> generic that handles all the common aspects, using a formal function for
> the prefix part.
>
> Is there something wrong with that approach?
> Are there some caveat that I missed?
> Are there advantages in avoiding the generics in that situation, for
> example using a non-generic common function that takes an
> access-to-subprogram extra parameter?

There's nothing wrong with that approach. I've used it successfully many times.

--
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail
19

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 03/23/2012 09:29 AM, Natasha Kerensikova wrote:
>
> I happen to have encountered my very first compiler bug, or at least
> something that claims to be in the following message:
>
> +===========================GNAT BUG DETECTED==============================+
> | 4.6.2 20111026 (release) -=> GNAT AUX [FreeBSD64] (x86_64-aux-freebsd9.0) GCC error:|
> | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4134 |
> | Error detected at dressup-parsers-markdown.adb:184:4 [dressup-parsers-markdown.adb:1651:7 [markdown.adb:32:4]]|
> | Please submit a bug report; see http://gcc.gnu.org/bugs.html. |
> | Use a subject line meaningful to you and us to track the bug. |
> | Include the entire contents of this bug box in the report. |
> | Include the exact gcc or gnatmake command that you entered. |
> | Also include sources listed below in gnatchop format |
> | (concatenated together with no headers between files). |
> +================================================= =========================+
>
> So my first question is, would anyone be kind enough to try and
> reproduce that bug? The files involved are available individually at
> http://fossil.instinctive.eu/dressup...54531f8dcf7117
> or as a tarball at
> http://fossil.instinctive.eu/dressup...b886701222c342

I get:

jrcarter@jrcarter-gateway-1:~/Code/Natasha/Dressup-bf54531f8dcf7117$ gnatmake -p
-P markdown.gpr
object directory "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/obj" created
exec directory "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/bin" created
gcc-4.4 -c -gnatafnovy -gnateE -gnatwae -fstack-check -O3 -I- -gnatA
/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/markdown.adb
gnat1: invalid switch: -gnateE
gnatmake: "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/markdown.adb"
compilation error

--
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail
19

Natasha Kerensikova <lithiumcat@gmail.com> writes:

> I happen to have encountered my very first compiler bug, or at least
> something that claims to be in the following message:
>
> +===========================GNAT BUG DETECTED==============================+
> | 4.6.2 20111026 (release) -=> GNAT AUX [FreeBSD64] (x86_64-aux-freebsd9.0) GCC error:|

If you get a bug box, it's a compiler error!

Same (barring line number in decl.c) on Mac OS X with GCC 4.6.0 and GCC
4.8.0 20120314 (experimental) [trunk revision 185379].

On Fri, 23 Mar 2012 16:29:06 +0000 (UTC), Natasha Kerensikova wrote:

> I happen to have encountered my very first compiler bug, or at least
> something that claims to be in the following message

First, make sure your code is legal. In some cases GNAT crashes when
detects an error in the program. One method to find the problem is to
comment offending source code lines until it compiles and then twist it
this or that way.

> I guess the problem somehow involves generics:

Yep, there are always problems with generics in GNAT, usually related to
visibility. Use renaming/subtyping of the formal parameters. This might
help to work around bugs.

....
I think AdaCore should drop the current model and redesign generics from
scratch allowing sharing the bodies. The model is not only buggy. It makes
compilation painfully slow, consuming unreasonably huge amounts of memory
(3GB+).

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> First, make sure your code is legal. In some cases GNAT crashes when
> detects an error in the program. One method to find the problem is to
> comment offending source code lines until it compiles and then twist it
> this or that way.

It's easier to use the -gnatdO switch, which is documented
in debug.adb.

- Bob

On 03/23/2012 09:29 AM, Natasha Kerensikova wrote:
>
> I happen to have encountered my very first compiler bug, or at least
> something that claims to be in the following message:
>
> +===========================GNAT BUG DETECTED==============================+
> | 4.6.2 20111026 (release) -=> GNAT AUX [FreeBSD64] (x86_64-aux-freebsd9.0) GCC error:|
> | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4134 |
> | Error detected at dressup-parsers-markdown.adb:184:4 [dressup-parsers-markdown.adb:1651:7 [markdown.adb:32:4]]|
> | Please submit a bug report; see http://gcc.gnu.org/bugs.html. |
> | Use a subject line meaningful to you and us to track the bug. |
> | Include the entire contents of this bug box in the report. |
> | Include the exact gcc or gnatmake command that you entered. |
> | Also include sources listed below in gnatchop format |
> | (concatenated together with no headers between files). |
> +================================================= =========================+
>
> So my first question is, would anyone be kind enough to try and
> reproduce that bug? The files involved are available individually at
> http://fossil.instinctive.eu/dressup...54531f8dcf7117
> or as a tarball at
> http://fossil.instinctive.eu/dressup...b886701222c342

I get:

jrcarter@jrcarter-gateway-1:~/Code/Natasha/Dressup-bf54531f8dcf7117$ gnatmake -p
-P markdown.gpr
object directory "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/obj" created
exec directory "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/bin" created
gcc-4.4 -c -gnatafnovy -gnateE -gnatwae -fstack-check -O3 -I- -gnatA
/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/markdown.adb
gnat1: invalid switch: -gnateE
gnatmake: "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/markdown.adb"
compilation error

--
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail
19

On 2012-03-23, Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:
> Natasha Kerensikova <lithiumcat@gmail.com> writes:
>
>> Hello,
>>
>> I happen to have encountered my very first compiler bug, or at least
>> something that claims to be in the following message:
>>
>> +===========================GNAT BUG DETECTED==============================+
>> | 4.6.2 20111026 (release) -=> GNAT AUX [FreeBSD64] (x86_64-aux-freebsd9.0) GCC error:|
>> | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4134 |
>> | Error detected at dressup-parsers-markdown.adb:184:4 [dressup-parsers-markdown.adb:1651:7 [markdown.adb:32:4]]|
>
> This seems similar to http://gcc.gnu.org/PR43806, the workaround for
> which is not to use -gnatE. Were you compiling with -gnatE?

No, there is no gnatE in my gpr file. I haven't seen any way of
overriding it should it be somehow on by default.

I do have -gnateE though, but as far as I can tell it's completely
unrelated.

Just as a double-check, I tried compling with -gnatE and/or without
-gnateE, but it did not change anything in the compiler output.


Thanks for your help,
Natasha

On 2012-03-23, Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
>> So my first question is, would anyone be kind enough to try and
>> reproduce that bug? The files involved are available individually at
>> http://fossil.instinctive.eu/dressup...54531f8dcf7117
>> or as a tarball at
>> http://fossil.instinctive.eu/dressup...b886701222c342
>
> I get:
>
> jrcarter@jrcarter-gateway-1:~/Code/Natasha/Dressup-bf54531f8dcf7117$ gnatmake -p
> -P markdown.gpr
> object directory "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/obj" created
> exec directory "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/bin" created
> gcc-4.4 -c -gnatafnovy -gnateE -gnatwae -fstack-check -O3 -I- -gnatA
> /home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/markdown.adb
> gnat1: invalid switch: -gnateE
> gnatmake: "/home/jrcarter/Code/Natasha/Dressup-bf54531f8dcf7117/markdown.adb"
> compilation error

Could you please try without -gnateE switch (removing line 32 from
markdown.gpr)? It has been shown to be irrelevant for the error.


Thanks for your help,
Natasha

On 2012-03-23, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Fri, 23 Mar 2012 16:29:06 +0000 (UTC), Natasha Kerensikova wrote:
>
>> I happen to have encountered my very first compiler bug, or at least
>> something that claims to be in the following message
>
> First, make sure your code is legal. In some cases GNAT crashes when
> detects an error in the program. One method to find the problem is to
> comment offending source code lines until it compiles and then twist it
> this or that way.

I tried that method, until there was so much to remove that nothing made
sense anymore. As far as I can tell, any "local" generic instantiation
in that package triggers the compiler error.

Surprisingly (at least for me), the error is triggered on the first
instantiation, even though the message reports the declaration location
first and then only the instantiation location.

>> I guess the problem somehow involves generics:
>
> Yep, there are always problems with generics in GNAT, usually related to
> visibility. Use renaming/subtyping of the formal parameters. This might
> help to work around bugs.

I don't really understand how visibility comes into play here, since
declaration, body and instantiation all reside in the same package body.
However I admit that compiler writing is arcane enough to lead to
unintuitive situation, but such a flat single isolated namespace should
be the easiest to deal with.


Thanks for your help,
Natasha

On 2012-03-23, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> First, make sure your code is legal. In some cases GNAT crashes when
>> detects an error in the program. One method to find the problem is to
>> comment offending source code lines until it compiles and then twist it
>> this or that way.
>
> It's easier to use the -gnatdO switch, which is documented
> in debug.adb.

I tried compiling my code with that extra flag, and I got exactly the
same error output.

I don't know really know what conclusion to draw from there.
Documentation says it makes the compiler fail faster, I guess minimizing
the surface for potential other errors.

Anyway, I tend to believe my code to be legal, since it's very close to
the previous version that did compile and run correctly. But then again,
even small differences can affect legality...



Thanks for your help,
Natasha

On 03/23/2012 02:23 PM, Natasha Kerensikova wrote:
>
> Could you please try without -gnateE switch (removing line 32 from
> markdown.gpr)? It has been shown to be irrelevant for the error.

jrcarter@jrcarter-gateway-1:~/Code/Dressup-bf54531f8dcf7117$ gnatmake -p -P markdown
object directory "/home/jrcarter/Code/Dressup-bf54531f8dcf7117/obj" created
exec directory "/home/jrcarter/Code/Dressup-bf54531f8dcf7117/bin" created
gcc-4.4 -c -gnatafnovy -gnatwae -fstack-check -O3 -I- -gnatA
/home/jrcarter/Code/Dressup-bf54531f8dcf7117/markdown.adb

GNAT 4.4.6
Copyright 1992-2008, Free Software Foundation, Inc.

Compiling: /home/jrcarter/Code/Dressup-bf54531f8dcf7117/markdown.adb (source
file time stamp: 2012-03-20 12:29:06)
138 lines: No errors

raised STORAGE_ERROR : stack overflow (or erroneous memory access)
gnatmake: "/home/jrcarter/Code/Dressup-bf54531f8dcf7117/markdown.adb"
compilation error

--
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail
19

On 23.03.12 22:40, Natasha Kerensikova wrote:
> On 2012-03-23, Robert A Duff<bobduff@shell01.TheWorld.com> wrote:
>> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de> writes:
>>
>>> First, make sure your code is legal. In some cases GNAT crashes when
>>> detects an error in the program. One method to find the problem is to
>>> comment offending source code lines until it compiles and then twist it
>>> this or that way.
>>
>> It's easier to use the -gnatdO switch, which is documented
>> in debug.adb.
>
> I tried compiling my code with that extra flag, and I got exactly the
> same error output.
>
> I don't know really know what conclusion to draw from there.

A bug seems present, with or without switches, in GNAT GPL 2011/Mac, too.

+===========================GNAT BUG DETECTED==============================+
| GPL 2011 (20110419) (x86_64-apple-darwin10.2.0) GCC error: |
| in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4121 |
| Error detected at dressup-parsers-markdown.adb:184:4 [dressup-parsers-markdown.adb:1651:7 [markdown.adb:32:4]]|

From the looks of it, it seems there is a probability that
the bug is related to passing information between GNAT
and other parts of GCC. The rest is speculation by mere mortals :-)


I worked around by adding switch -gnat95 and then mechanically following
the compiler's complaints. Less than I did might do the trick, though,
with GNAT at least, or any compiler that accepts Ada 2005 from the RTS in
Ada 95 programs.

http://home.arcor.de/bauhaus/Ada/Dre...f8dcf7117.diff

(A huge fraction of the patch is just syntax.)


I have let warnings about Ada.Containers (being 2005) be warnings.
The same relaxed attitude might work with GNAT and the new Strings.Fixed,
the one with the From parameter.

I seem not to have changed the generics part which you have been mentioning.
Moreover, I have added generics where procedures such as Iterate require
anonymous subprogram pointers now---no fancy downwards closures needed
here, though, and simple instantiations would do.

The resulting executable bin/markdown does output HTML for
*, \n==, etc., but I'm not sure that I have been sufficiently meticulous.
(Is bin/markdown supposed to successfully run a test suite yet?
I found test cases in something called MarkdownTest_1.0.zip,
which has a driver program written in Perl in it. I haven't used
it directly, but fed Tests/Tabs.text from this distribution
to bin/markdown and compared the results, just to see if I hadn't
messed up).

On 2012-03-24, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> wrote:
> A bug seems present, with or without switches, in GNAT GPL 2011/Mac, too.
>
> +===========================GNAT BUG DETECTED==============================+
>| GPL 2011 (20110419) (x86_64-apple-darwin10.2.0) GCC error: |
>| in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4121 |
>| Error detected at dressup-parsers-markdown.adb:184:4 [dressup-parsers-markdown.adb:1651:7 [markdown.adb:32:4]]|
>
> From the looks of it, it seems there is a probability that
> the bug is related to passing information between GNAT
> and other parts of GCC. The rest is speculation by mere mortals :-)

According to you and Simon Wright, it seems useful to report this bug
then. Now I just have to figure out to who and how, and maybe work out a
minimal test case.

I still have trouble interpreting Jeffrey Carter's results though.

> I worked around by adding switch -gnat95 and then mechanically following
> the compiler's complaints. Less than I did might do the trick, though,
> with GNAT at least, or any compiler that accepts Ada 2005 from the RTS in
> Ada 95 programs.
>
> http://home.arcor.de/bauhaus/Ada/Dre...f8dcf7117.diff
>
> (A huge fraction of the patch is just syntax.)

Thanks a lot, I will try to study that patch. I'm still surprised
2005 vs 95 can have something to do with it.

> The resulting executable bin/markdown does output HTML for
> *, \n==, etc., but I'm not sure that I have been sufficiently meticulous.
> (Is bin/markdown supposed to successfully run a test suite yet?
> I found test cases in something called MarkdownTest_1.0.zip,
> which has a driver program written in Perl in it. I haven't used
> it directly, but fed Tests/Tabs.text from this distribution
> to bin/markdown and compared the results, just to see if I hadn't
> messed up).

It is supposed to almost pass the test. It's a redesign from a
previous-working but (IMHO) ugly version, available at
http://fossil.instinctive.eu/dressup/info/de3a2cbc2d

Specifically, the "known failures", that I consider as "won't fix" are:
- I don't add an extra end-of-line when the file does not end with
one, but that only makes a difference in code blocks, with
</code></pre> being at the end of the line vs on the next line.
- I don't render empty href attributes, so there is a <a>stuff</a>
vs <a href="">stuff</a>.
- I don't remove spaces in a line that only contain them, again that
is only significant in code blocks (in
"Markdown Documentation - Basics.text" there is a code block with
two lines containing only 8 spaces, 4 of them are removed as the
code block marker, and the remaining 4 are output, while the
reference HTML has a spaceless empty line instead).



Thanks again for your help,
Natasha