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

Initialization of opaque fields with unknown size #1084

Open
jklmnn opened this issue Jun 23, 2022 · 2 comments
Open

Initialization of opaque fields with unknown size #1084

jklmnn opened this issue Jun 23, 2022 · 2 comments
Labels
architectural decision Discussion of design decision specification Related to specification package (e.g., specification parsing)

Comments

@jklmnn
Copy link
Member

jklmnn commented Jun 23, 2022

Context and Problem Statement

Currently the only way to initialize opaque fields in the spec is to either use a static aggregate or a function. While the static aggregate works well when the size is known sometimes it's required to zero-initialize an opaque field whose size is not known statically. In this case the only way to initialize this field is by using a function.

Use Cases

Zero-initialization of fields with a dynamic size that are modified later (e.g. a signature or hash).

Considered Options

O1

Using others to match whatever size the opaque field has with a static value.

Opaque_Field := [others => 0];

+ Close to Ada syntax
+ Allows custom values for all bytes
Only allows a single value for all bytes

O2

Using a range assignment:

Opaque_Field := [1 .. 8 => 255, 9 .. Opaque_Field_Length => 0];

+ Close to Ada syntax
+ More flexible in terms of different initial values for different ranges
Always requires the length to be known via a variable
Additional non-overlap checks necessary

O3

Using an reset aspect:

Opaque_Field'Reset (Opaque_Field_Length, 0);

+ Consistent to other Reset aspects such as for messages and sequences
Less flexible as it only allows a single value to be set
Always requires the length to be known via a variable

Decision Outcome

O1

@jklmnn jklmnn added the architectural decision Discussion of design decision label Jun 23, 2022
@jklmnn jklmnn added this to To do in RecordFlux 0.6 via automation Jun 23, 2022
@jklmnn jklmnn added the specification Related to specification package (e.g., specification parsing) label Jun 23, 2022
@senier
Copy link
Member

senier commented Jun 24, 2022

@jklmnn Would you allow multiple ranges in O2? If so, could please you add an example for that? In that case, a drawback would also be additional checks necessary to ensure non-overlap.

@jklmnn
Copy link
Member Author

jklmnn commented Jun 24, 2022

I updated O2.

@senier senier removed this from To do in RecordFlux 0.6 Aug 23, 2022
@senier senier added this to To do in RecordFlux Future via automation Aug 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architectural decision Discussion of design decision specification Related to specification package (e.g., specification parsing)
Projects
No open projects
Development

No branches or pull requests

2 participants