Spec proposal

[Ali Fardan]

On 2020-10-23 01:01, Sean Conner wrote:
>   Given how easy it is, I'm surprised there aren't more.  But by 
> searching
> the mailing list, I did fine reference to two Gemini-text-to-HTML
> converters:
> 
> 	https://github.com/LukeEmmet/GemiNaut/blob/master/GemiNaut/GmiConverters/GmiToHtml.r3
> 	(written in Rebol, a blast from the past)
> 
> 	https://git.sr.ht/~sotirisp/qute-gemini
> 	(Gemini text to Markdown to HTML in python3)

Interesting, still would like to have my own.

>   And here are some comments from trying it out.  I wrote a simple 
> Gemini
> text file (with very long lines) and ran your test program over it.  In 
> the
> output you have some garbage data on the very first line:
> 
> 00000000: 88 DB CB 23 20 4C 6F 72 65 6D 20 69 70 73 75 6D ...# Lorem 
> ipsum
> 00000010: 20 64 6F 6C 6F 72 20 73 69 74 20 61 6D 65 74 2C  dolor sit 
> amet,
> 
>   Thoughts:  sounds like you have some unitialized memory.  Aside from 
> the
> garbage bytes, the output did not match the input as the pre-formatted 
> block
> input did not have the ``` guards.  And the last blank line was not 
> included
> in the output either.

Thanks for taking the time, I'm going to write tests for the code now,
I haven't done that yet, I should probably be able to encounter that
bug again.  However, just in case I don't would you like to send me the
file you used to test with?

>   I also ran it under valgrind [1] and found a leak in the happy path:
> 
> [spc]lucy:/tmp/libgemtext>valgrind --show-reachable=yes
> --leak-check=full ./test </tmp/text.gemini >/tmp/t.gmi
> ==26859== Memcheck, a memory error detector.
> ==26859== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et 
> al.
> ==26859== Using LibVEX rev 1575, a library for dynamic binary 
> translation.
> ==26859== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
> ==26859== Using valgrind-3.1.1, a dynamic binary instrumentation 
> framework.
> ==26859== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et 
> al.
> ==26859== For more details, rerun with: -v
> ==26859==
> ==26859== Conditional jump or move depends on uninitialised value(s)
> ==26859==    at 0x804A2C1: strlcat (strlcat.c:38)
> ==26859==    by 0x8049C7E: _line_append (encode.c:198)
> ==26859==    by 0x8049EF5: gemtext_encode (encode.c:263)
> ==26859==    by 0x804A182: gemtext_encode_fd (encode.c:339)
> ==26859==    by 0x804A1FB: gemtext_encode_file (encode.c:359)
> ==26859==    by 0x804867A: main (test.c:15)
> ==26859==
> ==26859== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 12 from 
> 1)
> ==26859== malloc/free: in use at exit: 7,200 bytes in 1 blocks.
> ==26859== malloc/free: 86 allocs, 85 frees, 84,247 bytes allocated.
> ==26859== For counts of detected errors, rerun with: -v
> ==26859== searching for pointers to 1 not-freed blocks.
> ==26859== checked 55,588 bytes.
> ==26859==
> ==26859==
> ==26859== 7,200 bytes in 1 blocks are possibly lost in loss record 1 of 
> 1
> ==26859==    at 0x400579F: realloc (vg_replace_malloc.c:306)
> ==26859==    by 0x8049C56: _line_append (encode.c:194)
> ==26859==    by 0x8049D5D: gemtext_encode (encode.c:224)
> ==26859==    by 0x804A182: gemtext_encode_fd (encode.c:339)
> ==26859==    by 0x804A1FB: gemtext_encode_file (encode.c:359)
> ==26859==    by 0x804867A: main (test.c:15)
> ==26859==
> ==26859== LEAK SUMMARY:
> ==26859==    definitely lost: 0 bytes in 0 blocks.
> ==26859==      possibly lost: 7,200 bytes in 1 blocks.
> ==26859==    still reachable: 0 bytes in 0 blocks.
> ==26859==         suppressed: 0 bytes in 0 blocks.
> 
>   You will also want to check the non-happy paths for memory leaks.  In 
> my
> experience, memory leaks are more likely in the non-happy path because
> programmers rarely think through the non-happy path, and it's annoying 
> to
> write code to properly handle the non-happy paths in C.
> 
>   But I think it's wonderful that there was only one leak, and possibly 
> an
> easy one to fix.  The library itself appears easy to use (if you know 
> C).
> Good job.

Oh yeah, I ran valgrind, on my test file though, which didn't trigger
that, I wouldn't call it a real test file because it was the end of the
day, I just wanted to see if it works.