You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The code that takes the string for initial / max buffer size and parses it to a number doesn't handle bytes. It's also replicated 4 times across BP3/BP4, so since there is already a helper, why not consolidate the entire thing, and do it right?.
BytesFactor understands the suffixes "kb", "mb", "gb", and "b"/"bytes". However the parsing code that calls it assumes that the suffix is exactly two characters always, so "b"/"bytes" will never be understood.
There is helper::EndsWith -- this sounds like a good use for it. It supports case-insensitive match, which would make it understand "GB" etc as well. Finally, why not support a plain number, too? That's what tripped me up originally, I though just saying "1024" should work.
By the way, this is clearly a low priority item.
The text was updated successfully, but these errors were encountered:
The code that takes the string for initial / max buffer size and parses it to a number doesn't handle bytes. It's also replicated 4 times across BP3/BP4, so since there is already a helper, why not consolidate the entire thing, and do it right?.
BytesFactor
understands the suffixes "kb", "mb", "gb", and "b"/"bytes". However the parsing code that calls it assumes that the suffix is exactly two characters always, so "b"/"bytes" will never be understood.There is
helper::EndsWith
-- this sounds like a good use for it. It supports case-insensitive match, which would make it understand "GB" etc as well. Finally, why not support a plain number, too? That's what tripped me up originally, I though just saying "1024" should work.By the way, this is clearly a low priority item.
The text was updated successfully, but these errors were encountered: