From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45642) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SZ1C5-0005cW-5B for qemu-devel@nongnu.org; Mon, 28 May 2012 10:45:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SZ1C2-00040v-2K for qemu-devel@nongnu.org; Mon, 28 May 2012 10:45:12 -0400 Received: from cantor2.suse.de ([195.135.220.15]:54364 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SZ1C1-0003zv-Pa for qemu-devel@nongnu.org; Mon, 28 May 2012 10:45:10 -0400 Message-ID: <4FC38F6D.6020400@suse.de> Date: Mon, 28 May 2012 16:45:01 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1338138128-53411-1-git-send-email-andreas.faerber@web.de> <4FC36418.3080502@web.de> In-Reply-To: <4FC36418.3080502@web.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH for-1.1?] slirp: Avoid redefining MAX_TCPOPTLEN List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Paolo Bonzini , qemu-devel@nongnu.org, Stefan Weil -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 28.05.2012 13:40, schrieb Jan Kiszka: > On 2012-05-27 14:02, Andreas F=C3=A4rber wrote: >> MAX_TCPOPTLEN is being defined as 32. Darwin has it as 40, >> causing a warning. The value is only used to declare an array, >> into which currently 4 bytes are written at most. It should >> therefore be acceptable to adopt the host's definition. >>=20 >> Therefore only define MAX_TCPOPTLEN if not already defined. >>=20 >> Signed-off-by: Andreas F=C3=A4rber ---=20 >> slirp/tcp_output.c | 2 ++ 1 files changed, 2 insertions(+), 0 >> deletions(-) >>=20 >> diff --git a/slirp/tcp_output.c b/slirp/tcp_output.c index >> 779314b..9815123 100644 --- a/slirp/tcp_output.c +++ >> b/slirp/tcp_output.c @@ -47,7 +47,9 @@ static const u_char >> tcp_outflags[TCP_NSTATES] =3D { }; >>=20 >>=20 >> +#ifndef MAX_TCPOPTLEN #define MAX_TCPOPTLEN 32 /* max # bytes >> that go in options */ +#endif >>=20 >> /* * Tcp output routine: figure out what should be sent and send >> it. >=20 > Let's be conservative for 1.1 and do #undef MAX_TCPOPTLEN instead. > Does this work as well? For Leopard I'd guess so. What I had in mind here was that it was suggested earlier by one of you to use host defines for 1.2 wherever possible, and this seemed like low-hanging fruit. I do see Stefan's point though. An alternative, host-overriding version would be: #if !defined(MAX_TCPOPTLEN) || MAX_TCPOPTLEN < 4 #undef MAX_TCPOPTLEN ... #endif Stefan's point in turn means that defining MAX_TCPOPTLEN to something larger than the host supports could in theory cause trouble when used with host functions (which we currently don't seem to). A safe host-adopting version would be: #if defined(MAX_TCPOPTLEN) && MAX_TCPOPTLEN >=3D 4 #define SLIRP_MAX_TCPOPTLEN MAX_TCPOPTLEN #else #define SLIRP_MAX_TCPOPTLEN 32 #endif and use opt[SLIRP_MAX_TCPOPTLEN]. In that case we could probably just rename MAX_TCPOPTLEN -> SLIRP_MAX_TCPOPTLEN in the first place. Yet another option would be to drop MAX_TCPOPTLEN and to hardcode the actually used opt[4]. Which do you prefer? :-) Andreas - --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBAgAGBQJPw49tAAoJEPou0S0+fgE/o5cP+gKOS0NJVOWl+XOIB1Pb+xgs WZ7f5Uiv0zAuzzcb4VLsB4XcWrxdkKdE2X284OFQyZIeya6IWuHuh35XCDDo1IG7 NwoV/rlZVRG3ttFEG1+6H49dgx/UeveyCs8kKsUQahO2teq423M4fStWhxky8SsQ sxPoJZTw5gOAyQLzGPO8kZ+3jXwxm9wgsEYvjhqKz7HVHuxcy2EHbYDxYeuRtJnf orwaUEVrGfwOwjDZF4E3R+x8z6YFjQ6a2/zsNnzeSzyXe67Mtmwfq/HSBmYpl6pY YQSAxLrrOUL5jCXzckL8GoW4YKfNgsz8rcqK5RRBI27JPVQj+bdVJSbR0N6E4EAT 50u6uFSWV/uJFMu0f83fC2uiEt8c0i3dYDNmWZXKytdl9KfHu2SQiVqV7GfxcszT Q4x0S9qnjB1P+Sh8Gtz61r8OQEAd9HssEaEbruzddvjXwuMJizcQKUZunO7PPx8V EkWKIDwg/hAcIVody1j3T6llShc+LVfwDmaajFhLPK9lqm6sw15HwZ9V9E7ww0GD DxRvVYud/XL4Zn6XpJVfozgQyAwWYKDduEZNIxA6YlIgtignXA8X+0wpRGKAJhea ttIO9PBpeOMTGhw5rpvo1MtyPrQXyk0XKNpL/vpseQfnt3x9Asfww0qYrTLlejuW X1ukGz9cleIqZyog5IHQ =3DqYtt -----END PGP SIGNATURE-----