Re: npf build break

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Tue, Nov 26, 2013 at 16:16:22 +0100, Joerg Sonnenberger wrote:

> On Tue, Nov 26, 2013 at 06:25:25AM +0400, Valery Ushakov wrote:
> > On Tue, Nov 26, 2013 at 00:25:55 +0000, Mindaugas Rasiukevicius wrote:
> > 
> > > Patrick Welche <prlw1%cam.ac.uk@localhost> wrote:
> > > > I'm seeing on -current/amd64 with gcc 4.5.4:
> > > > 
> > > > /usr/src/usr.sbin/npf/npftest/libnpftest/npf_table_test.c:27:6: error:
> > > > initializ er element is not constant
> > > > /usr/src/usr.sbin/npf/npftest/libnpftest/npf_table_test.c:27:6: error:
> > > > (near ini tialization for 'ip6_list[0][0]')
> > > > ...
> > > > 
> > > > 
> > > > static const uint16_t ip6_list[][8] = {
> > > >     {
> > > >         htons(0xfe80), 0x0, 0x0, 0x0,
> > > >         htons(0x2a0), htons(0xc0ff), htons(0xfe10), htons(0x1234)
> > > >     },
> > > > ...
> > > > 
> > > > uint16_t bswap16(uint16_t) __constfunc;
> > > >                        -> __attribute__((__const__))
> > > > 
> > > 
> > > This code has been for years.  Are you building with -O0 option?
> > 
> > May be we shouldn't depend on the optimizer to take care of this?
> 
> I tend to agree, but in this case it might be good enough to force
> __always_inline__?

I don't think that's enough to convince gcc that it's a constant
initializer, isn't it?

Also, is usage in preprocessor something that we care about?

-uwe