Closed MineRobber9000 closed 10 months ago
In the process of writing the implementations for incbinstr
and inchexstr
, I've come to the realization that I'm not exactly sure what start
and size
ought to entail when used. For incbin
, the obvious answer was "start
and size
are counted in bytes", but with incbinstr
and inchexstr
being able to include values that aren't a round number of bytes, what should start
and size
be measured in? Bits?
Hmmm, I think going by the logic, incbinstr
and inchexstr
should be measured in characters (which, in the set we allow, are also just bytes). But there's the issue of having ignorable characters inside these files (like whitespace and underscores).
So they should probably be measured by the multiple of bits each character is converted into, 1 and 4 respectively. I think it can be done by directly slicing the final output bitvec.to_bigint()
.
I'd say I'm proud of this PR. Ready for merge!
Adds 2 new forms of
incbin
:incbin(relative_filename, start)
: includesrelative_filename
starting from offsetstart
incbin(relative_filename, start, size)
: includessize
bytes fromrelative_filename
starting from offsetstart
I'd also like to make
incbinstr
andinchexstr
work similarly, but I'm not sure how to make it work (extra clarification for PR message that wasn't in the commit message:incbinstr
andinchexstr
go straight from a bitvec to a bigint with no interveningVec<u8>
step, so I can't slice it as easily as I canincbin
).When #191 gets merged,
ensure_inc_args
can be replaced with a call toquery.ensure_min_max_arg_number(1,3)?;
. Since I don't have that merged locally, I just wrote a quick and dirty function to do it.