Fw: [Git][NTPsec/ntpsec][master] 2 commits: Some u_long -> unsigned int changes.

[Joel Sherrill]

On Fri, Sep 23, 2016 at 2:09 PM, Kurt Roeckx <kurt at roeckx.be> wrote:

> On Fri, Sep 23, 2016 at 01:41:07PM -0500, Joel Sherrill wrote:
> > On Fri, Sep 23, 2016 at 1:08 PM, Gary E. Miller <gem at rellim.com> wrote:
> >
> > > Yo Eric!
> > >
> > >
> > > > These are valid because the invention and major uses of u_long in
> this
> > > > codebase predate the 64-bit transition - it may look like we're
> > > > narrowing size from 64 to 32 bits, but what we're actually doing
> is
> > > > replacing an earlier hack for guaranteeing 32-bit size by people
> > > > who cut their teeth on 16-bit ints.
> > >
> > > I disagree with this patch.
> > >
> > > -extern void    authtrust       (keyid_t, unsigned long);
> > > +extern void    authtrust       (keyid_t, unsigned int);
> > >
> > > In C, ints are not guaranteed to be longer than 16 bits.
> > >
> > > http://stackoverflow.com/questions/5256000/integer-
> > > size-in-c-depends-on-what#5256195
> > >
> > >
> > See C99 "5.2.4.2.1 Sizes of integer types" for the normative definition.
> >
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (pg 33 of PDF)
> >
> > If you have expectations of precise size of integers rather than required
> > minimum, you should used the stdint.h types like int32_t and uint64_t.
>
> Exactly.  And if it's just a minimum you could use int_least32_t.
>
> Agreed. It makes the expectations of the author on the variable's size
and expected range much more explicit.

-joel

>
> Kurt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160923/283bbc36/attachment.html>