Print

Print


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