[2016-09-03 00:40] Philipp Takacs <phil...@bureaucracy.de> > > part 1 text/plain 1166 > Hi > > [2016-09-02 23:11] Dmitry Bogatov <kact...@gnu.org> > > I am considering refactor m_convert function. It parses messages > > specification, like `1-c' or `15' and set corresponding messages > > selected. > > In general this is a good idea, but Markus mentioned some time ago that > he wants to redesign the messages specification. So before you start we > should discuss following questions: > > 1) Do we still want a redesign? > > 2) Should it be backward compatible? > > 3) What features do we want? > > 4) How should it look? > > We don't need to answer all questions in detail, but we should > have a rough idea about what we want.
I am fine with current format, except probably 5-2 should be treated as 2-5. > > It is rather complicated, and accepts message specification string as > > non-const, and it's non-trivial to make it const. (And there is FIXME > > in header of file!) While it is possible to write better parsing code, > > I propose to take advantage of re2c tool[1]. > > > > It is like flex or bison, but, unlike them, which read from file, re2c > > generates parser for C string (const char *). As far as I know, it is > > only string parser for C language. > > What speaks against using a standard lex (i.e. flex or bison) or what is > the advantage of re2c? > > It is like flex or bison, but, unlike them, which read from file Unless I missed the elefant, parser generated by flex read from FILE and you can't change it. After all, it was created for compiler development.
