Hi,
I just landed https://bugzilla.mozilla.org/show_bug.cgi?id=1423840, which
replaces the old prefs parser with a new one.
The new parser is faster, safer, gives better and more accurate error
messages, and is *much* easier to maintain.
It is also slightly stricter; see the list at the bottom of this email for
details (copied from the commit message). This increased strictness
required fixes in a few places (in Firefox, Talos, and Thunderbird) where
existing prefs files were doing bogus things that the old parser accepted,
such as junk characters between prefs, and integer literal values that
silently overflowed because they didn't fit in 32 bits.
Please keep an eye out for any other problems that might arise from this
change.
Nick
The new parser is slightly stricter than the old parser in a few ways.
- Disconcertingly, the old parser allowed arbitrary junk between prefs
(including at the start and end of the prefs file) so long as that junk
didn't include any of the following chars: '/', '#', 'u', 's', 'p'. I.e.
lines like these:
!foo@bar&pref("prefname", true);
ticky_pref("prefname", true); // missing 's' at start
User_pref("prefname", true); // should be 'u' at start
would all be treated the same as this:
pref("prefname", true);
The new parser disallows such junk because it isn't necessary and seems
like
an unintentional botch by the old parser.
- The old parser allowed character 0x1a (SUB) between tokens and treated it
like '\n'.
The new parser does not allow this character. SUB was used to indicate
end-of-file (*not* end-of-line) in some old operating systems such as
MS-DOS,
but this doesn't seem necessary today.
- The old parser tolerated (with a warning) invalid escape sequences within
string literals -- such as "\q" (not a valid escape) and "\x1" and "\u12"
(both of which have insufficient hex digits) -- accepting them literally.
The new parser does not tolerate invalid escape sequences because it
doesn't
seem necessary and would complicate things.
- The old parser tolerated character 0x00 (NUL) within string literals;
this is
dangerous because C++ code that manipulates string values with embedded
NULs
will almost certainly consider those chars as end-of-string markers.
The new parser treats NUL chars as end-of-file, to avoid this danger and
because it facilitates a significant optimization (described within the
code).
- The old parser allowed integer literals to overflow, silently wrapping
them.
The new parser treats integer overflow as a parse error. This seems
better,
and it caught existing overflows of places.database.lastMaintenance, in
testing/profiles/prefs_general.js (bug 1424030) and
testing/talos/talos/config.py (bug 1434813).
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
