Please add "require" tag to specify minimum required re2c version

[sirzooro]

User code may depend on some feature or bug fix added in specific re2c version, so it would be good to somehow specify minimum required re2c version. Attempt to generate code using older re2c version should fail. I propose following syntax:

/*!re2c:require:0.17*/

This code is rejected by current re2c version, so it will also prevent use of older re2c versions which do not implement this syntax. Please add this.

[skvadrik]

I see two problems with this proposal:

• Strict total ordering on the versions in not defined. For example, re2c-0.16.3 can contain bug fixes (upstream fixes, distribution patches, etc.) that are not present in re2c-0.17. So in case of bug fixes, this proposal wouldn't work.
• As for new features, they are always guarded by a new command line option or configuration. If you attempt to use old version that doesn't support this feature, re2c will complain about 'unrecognised configuration' or 'bad option', which is quite comprehensible. So in case of features, this new directive would be redundant.

Do you have a specific example that doesn't fall into one of the two categories?

[sirzooro]

Well, without strict ordering such protection would not be complete. However if user will stick to numbers assigned by you only, or to numbers from his Linux distribution, this will work. This is probably the "best effort" here. BTW, bison has option like this. I also saw some flex lexer which used preprocessor to check flex version, so similar option in re2c would have its use too.

I also wonder if new configuration option will be added for every new feature - some of them may be backward-compatible, i.e. generated code would be the same as from older re2c version if user did not use it. For example, instead of adding new command line switch -c for conditions you could enable this feature only when you detect that someone used it. If they are not used, extra code would not be added at all. You may also allow to specify options in .re file, like flex or bison do. This is useful thing, one can have one common makefile with one global rule to generate .c files from .re files which will use only common options needed every time, and specify anything extra in .re file itself.

And last thing - personally I prefer to get error "re2c version x.y is required" instead of "bad option", "syntax error" or anything else - in latter case I would have to spend some extra time to investigate why this does not work and how to fix it.

[skvadrik]

You may also allow to specify options in .re file, like flex or bison do.

The ability to replace any command-line option with an inplace configuration is one of my goals for the next release. This is really useful for projects that use multiple .re sources with different sets of options (one such project is re2c itself).

For example, instead of adding new command line switch -c for conditions you could enable this feature only when you detect that someone used it.

The problem here is not with backwards compatibility of new re2c versions (new re2c will accept both old code and new code, for sure). It's the old versions that may screw up new code (fail with an obscure error message, segfault, or worse: silently generate incorrect code). By explicitly documenting the need for an option we at least give old re2c a chance to fail with a good error message.

These options in fact behave exactly like the "require" directive you propose, but with a more fine-grained control. You have to demand exactly that what you need, not some vaguely defined set of features.

And last thing - personally I prefer to get error "re2c version x.y is required" instead of "bad option", "syntax error" or anything else - in latter case I would have to spend some extra time to investigate why this does not work and how to fix it.

Let me clarify a bit, "syntax error" (and other spurious errors) is what you get when you use a feature, but forget the option or configuration. You would still get the same error if you forget the "require" directive. On the other side, "bad option" is quite clear.

Whatever policy re2c uses for new features, switching policies on the fly is the worst thing to do. re2c is an old program and we cannot expect everyone to start using "require" instead of options.

[sirzooro]

Command line option provides some level of protection for new features, assuming of course that someone will use "official" way to build product which uses re2c. But if someone will try to execute re2c manually by executing it directly from command line, and do not pass required options, he will see something different than "bad option" - usually some kind of "syntax error".

Bug fixes are another story - there are no options to enable or disable them, so user will see either some re2c error, compilation error or (in worst case) some bug during runtime.

To summarize, both cases would benefit from this new "require" tag, especially the second one.