From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Felix Janda <felix.janda@posteo.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: libnetfilter_*: Use uint*_t instead of u_int*_t
Date: Fri, 15 May 2015 21:34:08 +0200 [thread overview]
Message-ID: <20150515193408.GA21843@salvia> (raw)
In-Reply-To: <20150515191039.GB16749@euler>
On Fri, May 15, 2015 at 09:10:39PM +0200, Felix Janda wrote:
> Hello,
>
> I've been trying to build many netfilter.org projects on a system with
> the musl libc library. Alas, I often get errors about undeclared
> u_int8_t, ... musl will declare these types when <sys/types.h> is
> included and _GNU_SOURCE or _BSD_SOURCE is set. However many
> netfilter.org projects don't include <sys/types.h>.
I suspected this when I applied the patch from the Alpine Linux guy
for libnetfilter_log just a while.
> On the other hand, changing the types to the <stdint.h> uint*_t works
> in most cases because <netinet/in.h> is often included, which (by POSIX)
> includes <inttypes.h> which includes <stdint.h>. (Sometimes <stdint.h> or
> <inttypes.h> is also directly included.)
Last time I looked into this, my conclusion was that it was safe to
migrate to uint*_t stdint types, but it would be good to double check.
> In some cases u_int*_t and uint*_t types are mixed, so I am going to
> prepare a patch series which changing them and making sure that the
> public headers explicitly include <stdint.h> if they use these types.
>
> Assuming these (relatively invasive in terms of changed lines of code)
> changes are acceptable, I have some questions:
>
> Are the linux_nfnetlink_*.h only used as includes from other headers?
> (so that they don't need an explicit #include <stdint.h>)
You can refresh those header files to get them in sync with the
kernel, that can come in several initial patches. They are cached
copies of what we have in the kernel, as a result you'll get __u*
types.
Then, the follow up patch can convert them to uint*
> Is there anything I need to be careful about?
>
> There are also kernel types (e.g. __u8) in some places. Should I also
> bother about these while I'm at it? These were not problematic for me
> since these (mostly?) kernel headers include <linux/types.h>.
Those should remain there, as they are part of a cached copy of what
we have in the linux kernel tree. The idea is basically to ensure
compilation of libraries independently of what linux headers you have
in your system (eg. people with very old header files).
next prev parent reply other threads:[~2015-05-15 19:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-15 19:10 libnetfilter_*: Use uint*_t instead of u_int*_t Felix Janda
2015-05-15 19:34 ` Pablo Neira Ayuso [this message]
2015-05-15 21:21 ` Felix Janda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150515193408.GA21843@salvia \
--to=pablo@netfilter.org \
--cc=felix.janda@posteo.de \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).