On Tue, Aug 29, 2023 at 09:58:53PM +0200, Thomas Haller wrote:
> On Tue, 2023-08-29 at 21:14 +0200, Pablo Neira Ayuso wrote:
> > On Tue, Aug 29, 2023 at 09:10:26PM +0200, Pablo Neira Ayuso wrote:
> > > On Tue, Aug 29, 2023 at 08:54:11PM +0200, Thomas Haller wrote:
> > > > An enum can be either signed or unsigned (implementation
> > > > defined).
> > > >
> > > > datatype_lookup() checks for invalid type arguments. Also check,
> > > > whether
> > > > the argument is not negative (which, depending on the compiler it
> > > > may
> > > > never be).
> > > >
> > > > Signed-off-by: Thomas Haller <thaller@xxxxxxxxxx>
> > > > ---
> > > > src/datatype.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/src/datatype.c b/src/datatype.c
> > > > index ba1192c83595..91735ff8b360 100644
> > > > --- a/src/datatype.c
> > > > +++ b/src/datatype.c
> > > > @@ -87,7 +87,7 @@ const struct datatype *datatype_lookup(enum
> > > > datatypes type)
> > > > {
> > > > BUILD_BUG_ON(TYPE_MAX & ~TYPE_MASK);
> > > >
> > > > - if (type > TYPE_MAX)
> > > > + if ((uintmax_t) type > TYPE_MAX)
> > >
> > > uint32_t ?
>
> The more straight forward way would be
>
> if (type < 0 || type > TYPE_MAX)
>
> However, if the enum is unsigned, then the compiler might see that the
> condition is never true and warn against that. It does warn, if "type"
> were just an "unsigned int". I cannot actually reproduce a compiler
> warning with the enum (for now).
Then, better keep it back?
> The size of the enum is most likely int/unsigned (or smaller, with "-
> fshort-enums" or packed). Is it on POSIX/Linux always guaranteed that
> an int is 32bit? I think not, but I cannot find an architecture where
> int is larger either. Also, if someone would add an enum value larger
> than the 32 bit range, then the behavior is compiler dependent, but
> most likely the enum type would be a 64 bit integer and
> "uint"/"uint32_t" would not be the right check.
I don't expect to ever have such a large number of types. Specifically
because there are API restrictions that apply in this case.
> All of this is highly theoretical. But "uintmax_t" avoids all those
> problems and makes fewer assumptions on what the enum actually is. Is
> there a hypothetical scenario where it wouldn't work correctly?
I was trying to figure out what this is fixing.
> > Another question: What warning does clang print on this one?
> > Description does not specify.
>
> this one isn't about a compiler warning. Sorry, I should not have
> included it in this set.
This TYPE_MAX will not ever become very large to require 64-bits.
With an implementation where enum is taken as signed, then this should
be sufficient too:
if (type > TYPE_MAX)
If this is not fixing up anything right now, I would prefer to keep
this back.
I'll take this series except this one.
Thanks.
