make poparser more robust

[xhebox]

as said in #50 (comment).

[kaniini]

hello! i am planning to switch alpine to gettext-tiny in the next release, v3.15.

we would like to work on improving gettext-tiny. i think improving poparser to work on a per-token basis makes a lot of sense as a first step.

do you have any preference on how poparser should be reimplemented?

[xhebox]

do you have any preference on how poparser should be reimplemented?

Nope. I have no idea yet. I am away from this project for a long time. We may want to discuss that on irc, discord, slack or whatever.

[rofl0r]

we would like to work on improving gettext-tiny.

did you encounter any specific issues so far ?

do you have any preference on how poparser should be reimplemented?

the design mistake i made with gettext-tiny is that i never intended for it to be used for actual translations, and doing a lot of micro-optimizations along the way, including no use of heap memory, which made the code quite difficult to deal with.
if i'd do it today i'd probably do it with lex/yacc oslt like that.
main issue with posix lex and yacc is that they dont produce library safe code, and poparser is meant to be used as library code. though since each tool requiring the parser is standalone that'd probably work out.

We may want to discuss that on irc, discord, slack or whatever.

i don't use slack nor discord. these are proprietary platforms, and require the resource-hungry browser to be open at all times. we already have an IRC chan called #sabotage

[xhebox]

if i'd do it today i'd probably do it with lex/yacc oslt like that.

Maybe just a hand-written parser, the syntax is pretty simple.

[kaniini]

did you encounter any specific issues so far ?

no, but we haven't switched it yet. however, one of the main motivations for doing so is that GNU gettext is a security disaster. hince the interest in ensuring gettext-tiny is as high quality as possible.

we already have an IRC chan called #sabotage

i joined that irc just now, lets talk there :)