However, how about two-stage parsing?
You have multiple
parse_ignored_table, so I assume you can skip a table even if you don't know its type yet... and you probably have a type code in the table header that lets you identify the specific table.
How about the following logic? You parse in a loop 54 "unknown" tables and put them in a HashMap with their type code as the key. Then you start building the structure and only now you get each table by its ID and parse its contents, returning an error if any of the required tables is not found or fails to parse.
By the way, if that's not a secret, what were the previous two crates you had to modify?
:O I really like this :) thank you very much for this great simplification @tanriol
or maybe I should just not bother and read the entire file into memory
bspeice Likely easier to read into memory, but using something like BufReader would make that easier. Most of the nom functions are abstracted over various Input* traits, so maybe have a concrete Reader that implements those?
I've tried to print the input bytes to figure out what's going on, and I've noticed that after the last sequence of bytes the function
parse_radius_attribute is called with an empty array, an example below:i: [20, 1f, 4d, 49, 57, 56, 42, 41, 42, 2d, 53, 57, 30, 31, 2d, 4d, 49, 54, 43, 48, 45, 4c, 4c, 2d, 39, 31, 35, 41, 2d, 57, 49]
i: []
anyone can point me what is the problem?
I think that the parser should stop here:
i: [20, 1f, 4d, 49, 57, 56, 42, 41, 42, 2d, 53, 57, 30, 31, 2d, 4d, 49, 54, 43, 48, 45, 4c, 4c, 2d, 39, 31, 35, 41, 2d, 57, 49]
I have my input as a slice of slices:
&[& [u8]], how could I make it working with nom?
That's likely easier.
Ok, thank you. I am looking for a DER object with der-parser. For now I am trying the parser on each increasing offset of the input, it is indeed pretty inefficent. But maybe I could first search for a pattern in my data and then parse only from here.
If you know it, you're probably safe from the "noise" prefix accidentally containing a matching structure, but, on the other hand, this sounds like a security vulnerability if the attacker could somehow control the "noise" part and inject the bad version of the structure.
However I am in fact scanning for all such structures in the input, so even if the attacker can insert bad cases, I think I should be able to still find the good ones, which is what matters in my case.
Returning to the original question, I'd take the specification, the expected data structure and find some sequence of 4+ bytes that's known ahead of time so that I could seek to it with
take_until
is there any way to have alt((a, b)) not return (&str, &str)
this is what i have
45 | pub fn alt<I: Clone, O, E: ParseError<I>, List: Alt<I, O, E>>(l: List) -> impl Fn(I) -> IResult<I, O, E> {
| ------------ required by this bound in `nom::branch::alt`
|
= note: expected enum `std::result::Result<(&str, &str), nom::internal::Err<(&str, nom::error::ErrorKind)>>`
found enum `std::result::Result<(&str, screen::settings::administration::parse_search::Criteria<'_>), nom::internal::Err<(&str, nom::error::ErrorKind)>>`
i think the issue is the two combinators return diff types, do they each need to return Either or something
Hello, I'm trying to write a parser that needs to parse Python-style variable names ([A-Za-z0-9_] characters, except the first character cannot be a number). I thought I would start by writing a custom version of nom::character::complete::alphanumeric1 that also accepts underscores, but when I tried copying it to my code and modifying it, I found that nom::traits is private. Any suggestions on the idiomatic way to do this with Nom?