> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Friday, 8 July 2022 16.10
>
> On Fri, Jul 08, 2022 at 01:52:12PM +0000, Mattias Rönnblom wrote:
> > On 2022-07-08 15:02, Morten Brørup wrote:
> > >> From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com]
> > >> Sent: Friday, 8 July 2022 14.44
> > >>
> > >> On 2022-07-07 23:44, Morten Brørup wrote:
> > >>>> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
> > >>>> Sent: Thursday, 7 July 2022 20.35
> > >>>>
[...]
> > >>>> static inline uint32_t
> > >>>> __rte_raw_cksum(const void *buf, size_t len, uint32_t sum)
> > >>>> {
> > >>>> - /* extend strict-aliasing rules */
> > >>>> - typedef uint16_t __attribute__((__may_alias__)) u16_p;
> > >>>> - const u16_p *u16_buf = (const u16_p *)buf;
> > >>>> - const u16_p *end = u16_buf + len / sizeof(*u16_buf);
> > >>>> + const void *end;
> > >>>
> > >>> I would set "end" here instead, possibly making the pointer const
> > >> too. And add spaces around '/'.
> > >>> const void * const end = RTE_PTR_ADD(buf, (len /
> sizeof(uint16_t)) *
> > >> sizeof(uint16_t));
> > >>>
> > >>
> > >> I don't think that makes the code more readable.
> > >
> > > It's only a matter of taste... Your code, your decision. :-)
> > >
> > > I think the spaces are required by the coding standard; not sure,
> though.
> > >
> >
> > If it isn't in the coding standard, it should be. But if you add
> spaces,
> > you have to break the line, to fit into 80 characters. A net loss,
> IMO.
> >
>
> Just FYI, lines up to 100 chars are ok now. Automated checkpatch checks
> as
> shown in patchwork only flag lines longer than that.
>
> /Bruce
The coding style [1] recommends max 80 characters, with an (easy to miss) note
below, saying that up to 100 characters are acceptable. I think it should be
simplified, replacing the 80 characters recommendation by a 100 characters
limit, so the additional note can be removed. Why still recommend 80, when we
really mean 100?
[1] https://doc.dpdk.org/guides/contributing/coding_style.html
