linux-kernel - Re: Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 16 Jan 2013 13:57:44 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	vapier@...too.org
Cc:	libc-alpha@...rceware.org, bhutchings@...arflare.com,
	yoshfuji@...ux-ipv6.org, amwang@...hat.com, tmb@...eia.org,
	eblake@...hat.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, libvirt-list@...hat.com,
	tgraf@...g.ch, schwab@...e.de, carlos@...temhalted.org
Subject: Re: Redefinition of struct in6_addr in <netinet/in.h> and
 <linux/in6.h>

From: Mike Frysinger <vapier@...too.org>
Date: Wed, 16 Jan 2013 12:04:56 -0500

> certainly true, but the current expectation is that you don't mix your ABIs.  
> if you're programming with the C library API, then use the C library headers.  
> if you're banging directly on the kernel, then use the kernel headers.  not 
> saying it's a perfect solution, but it works for the vast majority of use 
> cases.

This isn't how real life works.

GLIBC itself brings in some of the kernel headers, as do various library
headers for libraries other than glibc.

So you can get these conflicting headers included indirectly, and it is
of no fault of any of the various parties involved.

We have to make them work when included at the same time somehow, and
this is totally unavoidable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/