Closed Augustin-Zidek closed 7 months ago
Yes, I agree, thanks for the heads-up.
Changing those from char
to int8_t
is the right thing to do, but it's not an easy change; that change has other knock-on effects. Instead, for now, I changed the relevant flags from values of -1 to 127 (which is a safe change, if slightly hacky) and left a bread crumb trail of comments for future refactoring.
Thanks!
Looking at the fix: Will hmmerdbs produced with v3.4 be incompatible with the next version that includes this fix?
I believe they should be compatible. That code is only affecting error handling in converting sequence char symbols to digital codes (e.g. encoding 'A' as 0, 'C' as 1, etc.; unused ASCII chars got assigned a digital code of -1 for "unset"). Any valid index of real DNA sequences won't have invalid residue symbols.
(In checking into this, I found one more place I had to make a change for the new flag of 127.)
Thanks a lot!
hmmer.h
defines theFM_METADATA
struct:The
alph
andinv_alph
are typed aschar
, which could cause issues when people build HMMER with-funsigned-char
.E.g. the check in
makehmmerdb.c:659
:will be always
false
when HMMER is built with unsigned char.Would it make sense to change the type of
alph
andinv_alph
toint8_t
(orsigned char
) which has more strictly defined behaviour?Thanks!