I'm not quite sure what is error prone here as this has worked for decades and the particular issue is an edge case. Be ware that this object is one of the most used objects in xroot. It was orignally written to be super fast and use the minimum amount of memory. Accomplishing both does makes it more difficult to understand. However, given its position in the execution path I'd say leave it as is. On Mon, 17 Apr 2023, Guilherme Amadio wrote: > The fix looks good to me. However, It looks like the logic handling the `FTab` and `XTab` tables here is quite error-prone, so we should consider refactoring this a bit in the future. For example, rather than modifying `i` in place, we may call a `find_file_handle(i, FTab)`, then if that fails, call `find_file_handle(i - XRD_FTABSIZE, XTab)` or something like that. We could also move from malloc/free to a `std::array` for FTab (since it seems to have a compile-time fixed size), and a `std::vector` for the `XTab`. @abh What are your thoughts on this? > > -- > Reply to this email directly or view it on GitHub: > https://github.com/xrootd/xrootd/pull/1998#issuecomment-1510829520 > You are receiving this because you are subscribed to this thread. > > Message ID: ***@***.***> -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/pull/1998#issuecomment-1511557028 You are receiving this because you are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1