Bug #14934
common/config_opts.h: audit OPT_INT/OPT_UINT and handle incorrect signed uint
0%
Description
The fix for #13829 uncovered something that concerns me deeply: all the options that are marked as 'OPT_INT' when they should be 'OPT_UINT' and the fact that we have no good way to avoid the user from specifying a negative uint via the interface.
While a negative uint is completely valid, bitwise, from the user's pov it doesn't make much sense to pass "-1' to something that should expect an unsigned int (say, 'num_client') and have the cluster say "Good news everybody! num_client has been set to 18446744073709551615'. Of course, this would not actually happen right now because 'num_client' is set as an 'OPT_INT' instead of unsigned -- imo, it should be a uint though --, but it begs the question: how many unguarded OPT_UINTs do we have out there that could easily, deeply suffer from this?
History
#1 Updated by Daniel Oliveira about 8 years ago
I can take a look into this Joao.
#3 Updated by Sage Weil over 6 years ago
- Status changed from New to Won't Fix
This is obsolete with teh new options framework. What we probably want instead is an audit of min/max values.