Bug fix in fasta2* with very large reads (> 2Gb)

[a-ludi]

There was a bug if single read/scaffold exceeded 2 Gb because a 32-bit integer was used to store the length of the read buffer. I changed it to 64-bit integer.

[thegenemyers]

I've made the changes in my local copy and they will be reflected in the next commit along with a number of other updates. BTW, was were you reading in that was more than a 2GB read? I don't know of any single piece of DNA, e.g. a chromosome, that is that big.

…

-- Gene

On 3/27/19, 4:12 PM, Arne wrote: There was a bug if single read/scaffold exceeded 2 Gb because a 32-bit integer was used to store the length of the read buffer. I changed it to 64-bit integer. ------------------------------------------------------------------------ You can view, comment on, or merge this pull request online at: #39 Commit Summary * Bug fix in fasta2* with very large reads (> 2Gb) File Changes * *M* fasta2DAM.c <https://github.com/thegenemyers/DAZZ_DB/pull/39/files#diff-0> (6) * *M* fasta2DB.c <https://github.com/thegenemyers/DAZZ_DB/pull/39/files#diff-1> (8) Patch Links: * https://github.com/thegenemyers/DAZZ_DB/pull/39.patch * https://github.com/thegenemyers/DAZZ_DB/pull/39.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#39>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGkkNjKIdDqq2iRPmKgYxgC_tntb3o9jks5va4pggaJpZM4cODmQ>.

[a-ludi]

There is a very large scaffold (> 2Gbp) in the Axolotl assembly. ;-)