NFQUEUE: payload length C type

[thom311]

NFQUEUE: payload length C type

[thom311]

Yes this is unfortunate. But we cannot break ABI/API.

I think in the library you will find several places where the types mismatch. I close this issue because changing API is much more painful then the type mismatch.

Does this cause you any actual problems, beside being aesthetically wrong? Then please reopen or send a patch/pullrequest (but again, we cannot change API, we can only add new API with fixed behavior).

Thank you!!

[socketpair]

I have changed sources in a way that will NOT break API and ABI. This mean transitions int -> unit32_t and so on, and that will not break something because sizeof() is equal and values are actually positive in normal cases.

Please reopen if you agree.

[thom311]

I think int -> uint32_t is an ABI change. In C, the size of an int is not fixed and libnl is supposed to work also on systems where an int is not 32 bits -- well, maybe there are bugs and it doesn't work because of lack of testing. But it should work.

While it might work on my system/compiler, I am not confident that it will work on other systems. That's why I rather not change it.

I didn't reject #83 as a whole, but several changes do IMO change ABI/API.

For example, not OK:
int * -> unsigned int *
unsigned int -> uint32_t

OK:
uint8_t * -> const void *
uint8_t * -> const uint8_t *