qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, Stefan Weil <sw@weilnetz.de>
Subject: Re: [Qemu-devel] [PATCH for-1.1?] slirp: Avoid redefining MAX_TCPOPTLEN
Date: Mon, 28 May 2012 16:45:01 +0200	[thread overview]
Message-ID: <4FC38F6D.6020400@suse.de> (raw)
In-Reply-To: <4FC36418.3080502@web.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 28.05.2012 13:40, schrieb Jan Kiszka:
> On 2012-05-27 14:02, Andreas Färber 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.
>> 
>> Therefore only define MAX_TCPOPTLEN if not already defined.
>> 
>> Signed-off-by: Andreas Färber <andreas.faerber@web.de> --- 
>> slirp/tcp_output.c |    2 ++ 1 files changed, 2 insertions(+), 0
>> deletions(-)
>> 
>> 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] = { };
>> 
>> 
>> +#ifndef MAX_TCPOPTLEN #define MAX_TCPOPTLEN	32	/* max # bytes
>> that go in options */ +#endif
>> 
>> /* * Tcp output routine: figure out what should be sent and send
>> it.
> 
> 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 >= 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

- -- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nü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
=qYtt
-----END PGP SIGNATURE-----

      reply	other threads:[~2012-05-28 14:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-27 17:02 [Qemu-devel] [PATCH for-1.1?] slirp: Avoid redefining MAX_TCPOPTLEN Andreas Färber
2012-05-28  6:49 ` Paolo Bonzini
2012-05-28  7:00   ` Stefan Weil
2012-05-28 11:40 ` Jan Kiszka
2012-05-28 14:45   ` Andreas Färber [this message]

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=4FC38F6D.6020400@suse.de \
    --to=afaerber@suse.de \
    --cc=jan.kiszka@web.de \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sw@weilnetz.de \
    /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).