We don't need to know it's a pointer and can save 2 characters.
No functional changes. This is simply renaming "dec->p_fmt_in",
"decoder->p_fmt_in", "dec.p_fmt_in" and "packetizer->p_fmt_in"
These ranges are already covering the relevant ranges without being
case-insensitive, but if they are case-sensitive, for locales that have
can deal with some characters in these ranges, it makes the range
ambiguous and results in warnings about this:
CSSLexer.l:105: warning, the character range [?-?] is ambiguous in a
case-insensitive scanner
Instead of hardcoding the output file name in the
.l file, specify it on the command line instead.
In theory it would not be necessary to specify it at all as lex.yy.c
is the default, however overwriting the prefix will change this, so
we have to force it back to lex.yy.c so that ylwrap still works as
expected and can find the output file.
We do not hardcode it in the file anymore so that for Meson it can
properly specify the --outfile option and have it not overwritten by
the per-file option.
ylwrap expects the generated scanner file to be lex.yy.c. The prefix feature in yacc and lex will make sure yy will be replaced by prefix (css in this case).
Functions used outside the generated code will have to be correctly named (exccept YYSTYPE).
see e967f81f6a.
note, this does **not** affect cat-based module selection items
(of which there are just three in use by the core), since that
mechanism uses subcats not cats.
Currently, when encoding an ES category, the encoders had to check
whether they supported the ES category and return an error, forcing many
modules to be loaded and probed for nothing.
By splitting by ES category, we ensure that most encoder that would have
not supported the encoding anyway won't be probed. As a side effect, it
improves the documentation in the help output by only listing encoders
that will actually be able to encode the format, for instance in
aenc/venc/senc options in the transcode module. It will also provide a
better way for the UI to list the available encoders.
Scanner is used by both lexer and parser, so %param allows binding to
both, and css_parser is only used by the parser so there is no need to
declare it in the yylex function. As the function was not correctly
exposed to the lexer code, it was leading to different prototype for
both generated compile unit.