Skip to content

Fix vcfmerge format field handling for Number=G, INT8 PL, and dst buffer#2520

Open
sirus20x6 wants to merge 1 commit intosamtools:developfrom
sirus20x6:fix/vcfmerge-format-fields
Open

Fix vcfmerge format field handling for Number=G, INT8 PL, and dst buffer#2520
sirus20x6 wants to merge 1 commit intosamtools:developfrom
sirus20x6:fix/vcfmerge-format-fields

Conversation

@sirus20x6
Copy link

Summary

  • Fix le_to_i16 to le_to_i32 in BCF_BT_INT32 case of merge_localized_numberG_format_field — was reading only 2 of 4 bytes
  • Add bounds check for INT8 PL values before indexing into pl2prob[], matching existing INT16/INT32 checks
  • Fix src[j] = bcf_int32_vector_end to dst[j] in update_local_alleles — was writing to source buffer instead of destination

Test plan

  • Existing test suite passes (updated merge.LPL.3.out for correct missing values)
  • Verify merged Number=G FORMAT fields with 32-bit integer data

1. merge_localized_numberG_format_field: BCF_BT_INT32 case incorrectly
   used le_to_i16 instead of le_to_i32, causing wrong byte conversion
   for 32-bit integer FORMAT fields.

2. init_local_alleles: INT8 PL case lacked bounds checking on val before
   indexing into pl2prob[], risking out-of-bounds access. Added the same
   clamping guard (val>=0 && val<PL2PROB_MAX) already present in the
   INT16 and INT32 cases.

3. update_local_alleles: vector_end padding loop wrote to src[j] instead
   of dst[j], leaving the destination buffer with uninitialized trailing
   entries.
@sirus20x6 sirus20x6 force-pushed the fix/vcfmerge-format-fields branch from 4a205b5 to 0580579 Compare March 26, 2026 00:54
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.

1 participant