💾 Archived View for rawtext.club › ~sloum › geminilist › 002894.gmi captured on 2020-10-31 at 14:50:58. Gemini links have been rewritten to link to archived content

View Raw

More Information

-=-=-=-=-=-=-

<-- back to the mailing list

Spec proposal

Ali Fardan raiz at stellarbound.space

Fri Oct 23 04:09:56 BST 2020

- - - - - - - - - - - - - - - - - - - 

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 thatbug again. However, just in case I don't would you like to send me thefile 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 triggerthat, I wouldn't call it a real test file because it was the end of theday, I just wanted to see if it works.