Hi Michael, thanks for your bug report! Let's see:
[...] > Indeed reviewing the code here > > http://sources.debian.net/src/genometools/1.5.1-3/src/gtlua/encseq_lua.c?hl=83#L83 > > and taking into account the definition of luaL_checknumber on the one hand and > GtReadmode on the other: > > http://sources.debian.net/src/genometools/1.5.1-2/src/external/lua-5.1.5/src/lauxlib.c?hl=176#L176 > http://sources.debian.net/src/genometools/1.5.1-2/src/core/readmode_api.h#L23 > > this conversion appears to be dangerous at best: if a double value is return > that does not result in any of the int values 0, 1, 2, 3 all further code may > break. Yes, you are right. I think it would be best to adjust this interface to either have multiple Lua methods for each readmode, each calling gt_encseq_reader_reinit_with_readmode() with a correct literal readmode value, or to implement proper error reporting. The readmode is typically given directly in the call, not calculated using float arithmetics... But anyway, it is possible to end up with wrong parameters here in theory, and I will take care fix the problem. I will add a patch to the package and GenomeTools itself. Is this the only instance of such a problem or did your compiler just stop on the first error? I could imagine such an issue could come up in other places in the Lua bindings as well which could benefit from safer double-int conversion... > Best, > Michael Thanks, Sascha -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
