kjhermans
commented
4 years ago On 11-06-2020 22:55, Frans van Dorsselaer wrote:
Cool! Heb je tijd teveel of zo?
Ik snap de gedachte: robuust, ook tegen upsets. Is de bytecode b.v. geoptimaliseerd voor early single-bit-flip detectie?
Ik heb gedacht om het format van de bytecode moeilijker te maken op de volgende manieren:
-
de slotmap en labelmap erin opnemen.
-
een checksum van de totale bytecode en/of checksums per instructie.
-
replacement strings ergens in een dictionary erin opnemen.
Maar het wordt er alleen maar moeilijker van. Replacements zijn nu eigenlijk al iets te veel van het goede.
Dit smeekt om een fuzzer...
Input fuzzing zou ook eminent mogelijk moeten zijn, aangezien de voorspelbaarheid van het doorlopen van een run door de bytecode heel hoog is.
Je staat left-recursion toe. Hoe kan een limiet worden ingesteld?
Op zich is infinite loop detection vrij simpel: als je op dezelfde bytecode offset staat en dezelfde input position, zit je in een infinite loop. Een array met de grootte van de bytecode (eventueel wat dieper omdat je n-de orde recursie kunt krijgen) is dan alles wat je nodig hebt.
Limieten stel ik sowieso, aan alle buffers. In fact, ik zit nog met het probleem hoe ik in C op een makkelijke manier in dezelfde API zonder en met malloc() kan werken. Dat is nog niet simpel om dat elegant te doen.
Daarnaast: in PEG hoor je nooit een left-recursive rule te schrijven. Er is eigenlijk maar 1 reden om recursieve rules te definieren: semantische recursie in je inputs. Voor loops gebruik je iterators. Moet ook, omdat ook de rule:
INPUT <- . INPUT
weliswaar foutloos door je input wandelt, maar een stack genereert die even groot is als je input. En dat is gewoon onwenselijk. Bovenstaand wordt dus in packrat altijd geschreven als:
INPUT <- .*
Wiskundigen met hun fetisj voor recursie can go hang ;-)
Je zou i.p.v. PEG ook kunnen gaan voor een pika parser die left-recursion geheel voorkomt. Of wil je juist willekeurig groot kunnen handelen? Ik ga ervan uit dat de grammar van tevoren bekend is, of is het ook bedoeld voor runtime dynamisch gegenereerde parsers? Op zich wel, maar zoals ik zei: infinite loop detectie is ook vanuit de engine goed mogelijk. Ik ga eens even kijken naar die PIKA parser.
Leuke details: (uiteraard) is de compiler zelf-gegenereerd. Maar Perl boot-strapping, really?? ;) Er is maar 1 scripting taal die er toe doet.
En het feit dat de repo niet uitcheckt op Windows is zeker een feature? (tip: windows kan geen files/directories aan die 'AUX' heten, dat is een gereserveerde naam uit het MS-DOS tijdperk... zucht) Oh. Nou dat gaat veranderen per de commit van vandaag.
Dit viel mij het eerste op na een uurtje kijken; wat kan ik betekenen? Zie gesprek van gisteren.
Cool! Heb je tijd teveel of zo?
Ik snap de gedachte: robuust, ook tegen upsets. Is de bytecode b.v. geoptimaliseerd voor early single-bit-flip detectie? Dit smeekt om een fuzzer...
Je staat left-recursion toe. Hoe kan een limiet worden ingesteld? Je zou i.p.v. PEG ook kunnen gaan voor een pika parser die left-recursion geheel voorkomt. Of wil je juist willekeurig groot kunnen handelen? Ik ga ervan uit dat de grammar van tevoren bekend is, of is het ook bedoeld voor runtime dynamisch gegenereerde parsers?
Leuke details: (uiteraard) is de compiler zelf-gegenereerd. Maar Perl boot-strapping, really?? ;) En het feit dat de repo niet uitcheckt op Windows is zeker een feature? (tip: windows kan geen files/directories aan die 'AUX' heten, dat is een gereserveerde naam uit het MS-DOS tijdperk... zucht)
Dit viel mij het eerste op na een uurtje kijken; wat kan ik betekenen?