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-----
prev parent 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).