Fix a bug in .Ql handling that has been present since the beginning (2017).
authorschwarze <schwarze@openbsd.org>
Tue, 13 Aug 2024 12:43:55 +0000 (12:43 +0000)
committerschwarze <schwarze@openbsd.org>
Tue, 13 Aug 2024 12:43:55 +0000 (12:43 +0000)
commit0272cb5caf6c1add79ccc0b56bfd872c379e9fb2
tree746b0e058896b39ef8887fe9c19e2884cb49ea72
parent657921cb7a3fc7a744a44e9ca1ecc60c76c24669
Fix a bug in .Ql handling that has been present since the beginning (2017).

Since the .Ql macro action uses an output prefix of "'`" and an output
suffix of "`'", md_post_raw() would decrement the code_blocks state variable
even though md_pre_raw() had earlier neglected to increment it, hence
leaving the variable in an invalid negative state.  That in turn could
result in corrupt output in a variety of ways.

Fix this by checking in md_pre_raw() whether the prefix *contains* a
backtick rather than only checking whether it *starts* with a backtick.
For consistency, apply the same change to md_post_raw() even though
there was no bug in that function: all *suffixes* containing a backtick
actually contain it in the leading position.

Thanks to job@ for reporting this bug.  He noticed a particularly nasty
kind of output corruption: having .Ql in an input file would result
in ASCII_NBRSP (0x31) sneaking through into the output stream if later,
unrelated parts of the same input file directly or indirectly used
the \~ escape sequence, for example by using the .Ex macro.
usr.bin/mandoc/mdoc_markdown.c