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

Do not allow unused trailing bytes in BAM records #71

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

jakobnissen
Copy link
Member

Previously, the .data field of BAM records could have unused bytes near the end. This is acceptable, because the length of the actually used bytes is known from the fixed fields of the record.
It had the advantage of preventing frequent resizes, which was slow in Julia. However, from Julia 1.11 onwards, resizing is fast. Promising no non-coding bytes in the BAM records have the following advantages:

  • It may simplify some code in XAM
  • It allows an immutable struct holding a reference to the vector to resize the vector, signalling a change in the variable-length data.

This change is not user-facing and should be ready to merge.

Previously, the .data field of BAM records could have unused bytes near the end.
This is acceptable, because the length of the actually used bytes is known from
the fixed fields of the record.
It had the advantage of preventing frequent resizes, which was slow in Julia.
However, from Julia 1.11 onwards, resizing is fast.
Promising no non-coding bytes in the BAM records have the following advantages:
* It may simplify some code in XAM
* It allows an immutable struct holding a reference to the vector to resize
  the vector, signalling a change in the variable-length data.
@jakobnissen jakobnissen mentioned this pull request Mar 11, 2024
5 tasks
@@ -20,7 +20,7 @@ mutable struct Record <: XAMRecord
next_refid::Int32
next_pos::Int32
tlen::Int32
# variable length data
# This vector never has unused bytes at the end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment may be confusing outside the context of the previous design, maybe

Suggested change
# This vector never has unused bytes at the end
# This vector used to have unused bytes at the end, but no longer does

or something?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original comment intended to distinguish the fields that could vary in length from those that do not. From that standpoint, it does not need changing. If you'd like to add a comment specific to a field, perhaps it should go on the same line as the field.

@kescobo
Copy link
Member

kescobo commented Mar 11, 2024

LGTM. Do we also want to change the julia compat with this change to be 1.11+? I suppose it works with older versions, but may be slower?

@@ -20,7 +20,7 @@ mutable struct Record <: XAMRecord
next_refid::Int32
next_pos::Int32
tlen::Int32
# variable length data
# This vector never has unused bytes at the end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original comment intended to distinguish the fields that could vary in length from those that do not. From that standpoint, it does not need changing. If you'd like to add a comment specific to a field, perhaps it should go on the same line as the field.

@@ -41,7 +41,7 @@ function Base.convert(::Type{Record}, data::Vector{UInt8})
record = Record()
dst_pointer = Ptr{UInt8}(pointer_from_objref(record))
unsafe_copyto!(dst_pointer, pointer(data), FIXED_FIELDS_BYTES)
dsize = data_size(record)
dsize = record.block_size - FIXED_FIELDS_BYTES + sizeof(record.block_size)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This calculation occurs more than once. It deserves its own function, which may be separate from data_size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants