+1, let’s stick with u32... Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Dave Wallace
Sent: Monday, September 11, 2017 12:36 PM
To: Florin Coras <fcoras.li...@gmail.com>; Luke, Chris <chris_l...@comcast.com>
Cc: vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] u32 vs uint32_t

+1
On 09/11/2017 11:27 AM, Florin Coras wrote:
Hi Chris,

Personally, I’d like to enforce the use of u32. Is it an option to just replace 
all occurrences of uint32_t in ip.h/mpls.h?

Thanks,
Florin

On Sep 11, 2017, at 7:55 AM, Luke, Chris 
<chris_l...@comcast.com<mailto:chris_l...@comcast.com>> wrote:

For discussion: VPP has traditionally used its own fixed-width types, such as 
u32 and u64 and only uses standard types when referring to the external world 
(eg, to talk to libc, etc). Recently I’ve noticed the C99 variant, uint32_t 
creeping in more and into VPP internal matters. As a matter of style and 
consistency, which should we as a project be using?

Reason I ask: The recent MPLS patch (https://gerrit.fd.io/r/#/c/8371) uses both 
styles in .h files but doesn’t have stdint.h included in any path leading to 
those .h’s; Coverity appears to be fussy about this – it checks that all types 
used in a .h are defined in the scope of that .h. Upshot is that Coverity is 
balking at this and only 54% of the project now compiles under Coverity

To resolve the issue with Coverity, I am torn with adding “#include <stdint.h>” 
to ip.h/mpls.h to fix it where it happens, or just accept that humans are 
inconsistent and add it to vppinfra/types.h. Thoughts?

Chris.

_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
https://lists.fd.io/mailman/listinfo/vpp-dev





_______________________________________________

vpp-dev mailing list

vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>

https://lists.fd.io/mailman/listinfo/vpp-dev

_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Reply via email to