You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The align_after, align_before, pad_after, pad_before, and pad_size_to directives always write 0x00 bytes. I propose that these directives optionally accept a byte value to use when writing padding, keeping 0x00 as the default value when one is not present. For example #[bw(align_after(2048, 0xFF))] would write 0xFF instead of 0x00. The exact syntax is not important. It is possible that a user may want to use a different padding value for the before and after padding, so this should be specified for each directive rather than at the field or struct level.
This form of the directives does not make much sense in br since the value would serve no purpose when reading; however, the following code sample
strikes me as odd and needlessly duplicated in the case where the padding size is the same for both reading and writing. Perhaps #[brw(align_after(2048, 0xFF))] should be allowed?
The feature would improve the quality of my binrw code by eliminating unnecessary write_withs that only serve to pad with a different value. The format I am implementing a writer for uses different values when padding different fields and I need to match this in order for the hashes to match when roundtripping a file.
The text was updated successfully, but these errors were encountered:
The
align_after
,align_before
,pad_after
,pad_before
, andpad_size_to
directives always write0x00
bytes. I propose that these directives optionally accept a byte value to use when writing padding, keeping0x00
as the default value when one is not present. For example#[bw(align_after(2048, 0xFF))]
would write0xFF
instead of0x00
. The exact syntax is not important. It is possible that a user may want to use a different padding value for the before and after padding, so this should be specified for each directive rather than at the field or struct level.This form of the directives does not make much sense in
br
since the value would serve no purpose when reading; however, the following code samplestrikes me as odd and needlessly duplicated in the case where the padding size is the same for both reading and writing. Perhaps
#[brw(align_after(2048, 0xFF))]
should be allowed?The feature would improve the quality of my
binrw
code by eliminating unnecessarywrite_with
s that only serve to pad with a different value. The format I am implementing a writer for uses different values when padding different fields and I need to match this in order for the hashes to match when roundtripping a file.The text was updated successfully, but these errors were encountered: