Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Optionally specify padding value in derive directives #205

Open
widberg opened this issue Jun 14, 2023 · 0 comments
Open

[Feature] Optionally specify padding value in derive directives #205

widberg opened this issue Jun 14, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@widberg
Copy link

widberg commented Jun 14, 2023

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

#[br(align_after(2048))]
#[bw(align_after(2048, 0xFF))]

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.

@csnover csnover added the enhancement New feature or request label Sep 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants