Wow. Some of that is bizarre enough that I kinda want to go look at the old parser code, but I value my sanity enough to not do so. Nice work.
Can I presume that things which now trigger parsing issues are escaped or errored by the relevant prefs APIs? e.g. if a caller tries to set a pref name or value with an embedded NULL? Justin On Thu, Feb 1, 2018 at 1:04 PM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > 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 > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
