X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=xELdKzYNEIyLYhmcwkNe6pQ8/2ugRVVuqQ8sbUSQh/wsWJcZg/6A6
	NyluMaasMAbBqPK1HLBTcHoj6o/VwEP/6JwMjhReal02p9JBSKQn8YFM91Q2SesU
	2KZ7zX25qH7B1xFbLSPILoy7uOzIek4fudX878mg3KUspOXqwf6xSA=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=d52hNJbRP5XbcC4uPzfTVTo8jGA=; b=MBm0oLJUxDTNLh8UO/GVbEda3W2H
	Frpt2eDQMs2u7GMP4Z8U5n/+T9hrojOba3LzPG4cxM1A4MUeIi9f8evuMbMc/WYA
	ZIEw3pVTbGP0C6jImAJsvA13jDIXh+pWi6075D0MCNucEcb9Asvb0zqHRimVDZGR
	87Cpv60UvuBmwAM=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-Spam-SWARE-Status:	No, score=-3.9 required=5.0 tests=AWL,BAYES_00,KHOP_PGP_SIGNED,URI_HEX autolearn=no version=3.3.2
Date:	Mon, 12 Aug 2013 12:49:54 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Cc:	Daniel Stenberg <daniel AT haxx DOT se>
Subject:	Re: [64-bit] curl: fix -i option (include headers)
Message-ID:	<20130812104954.GD2691@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com, Daniel Stenberg <daniel AT haxx DOT se>
References:	<5207F5B0 DOT 5070708 AT nt DOT tuwien DOT ac DOT at>
MIME-Version:	1.0
In-Reply-To:	<5207F5B0.5070708@nt.tuwien.ac.at>
User-Agent:	Mutt/1.5.21 (2010-09-15)
X-Virus-Found:	No

--fXStkuK2IQBfcDe+
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Aug 11 22:36, Andreas Winkelbauer wrote:
> Hi,
>=20
> recently I stumbled across a bug in curl for 64-bit Cygwin regarding the
> -i option. This bug has already been discussed in April 2013:
>=20
> http://cygwin.1069669.n5.nabble.com/Difference-in-32-64-bit-curl-td98083.=
html
> (I can't reply directly since I was not subscribed to this mailinglist
> back then.)
>=20
> The problem is that the current version of curl always includes the
> protocol headers in the output (no matter if -i or --include or
> --no-include are used or not). This bug breaks scripts which use curl
> and expect it to not include the headers in the output.
>=20
> After some debugging I found out that the cause of the problem is a
> missing cast of the third argument of my_setopt in tool_operate.c:886
> (line numbers from curl 7.29.0)
>=20
> my_setopt(curl, CURLOPT_HEADER, config->include_headers);
>=20
> Here, config->include_headers is of type bool (1 byte) and my_setopt is
> a macro which calls curl_easy_setopt() and is defined in tool_setopt.h
> as follows:
>=20
> #define my_setopt(x,y,z) \
>   SETOPT_CHECK(tool_setopt(x, FALSE, config, #y, y, z))
>=20
> tool_setopt() is implemented in tool_setopt.c and uses va_arg(arg, long)
> to get the value of its sixth argument (which is
> config->include_headers). However, sizeof(long) =3D=3D 8, but sizeof(bool)
> =3D=3D 1 and thus va_arg(arg, long) returns a value !=3D 0 even if
> config->include_headers =3D=3D 0.
>=20
> I am not sure why there is no problem with other boolean configuration
> options like CURLOPT_FAILONERROR (corresponding to -f or --fail) which
> are processed in exactly the same way, e.g., in tool_operate.c:930
>=20
> my_setopt(curl, CURLOPT_FAILONERROR, config->failonerror);
>=20
> Also, there is no problem in 32-bit Cygwin and in 32/64-bit Linux. Maybe
> the bug is triggered by some missing or incorrect (alignment related)
> compiler switches?

Just FYI, this is very likely a bug which is only triggered on 64 bit
Cygwin due to the different way arguments are passed to functions.
The 1 byte bool value is sign extended to int (4 byte) and not to long
(8 byte).  This doesn't matter if the arg is passed in a register since
AMD64 always zero's the high 4 byte of a register when you store a=20
4 byte value in it.  But it matters as soon as the argument is passed
on the stack.

The difference between Cygwin and Linux is the calling convention.
Linux uses the SYSV ABI, with the first 6 args in registers before
subsequent regs are spilled on the stack.  Cygwin uses the MS ABI, with
only the first four args in registers.

So, type problems int vs. long in function args only start showing with
the 7th arg on Linux, but already with the 5th arg on Cygwin.


HTH,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--fXStkuK2IQBfcDe+
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJSCL3RAAoJEPU2Bp2uRE+gOcQP/iCYEo0Agb+EL+HQ2vaLUQe1
ewgbc//dhzSOA/dfe0ebm45a/bxGKe1WvkjI2gk/GPNj/IbB24CfheLpaFtQ2oU9
cYkEuENZeR3PuSmLCdK6T4lmZiJb+v5eVJLUp/ST2Dg66Fxw9WhLbVPlWR+9CgvW
MgNmBMl4gMzyNdYidfOeKoy4ulnuk0HaZZGsMJSCO1FrnlAwL1KpdmAxUX4qwKyU
Z2y7bRH9x27DtD5y6wQtf86UQ5YgIBxiQ+mo5RXk93iBMR9HjTyWUbm9OJV/+nQG
xiozKbIxXnXb4TzorH138K9/RZiuBdb/qjmBShIGgb3hpkbtCeAfJuEBVQyjmH56
U9vw10WWoKzSxG/Gbp1hvQDygfhflzwsazZF84bx5ViYTekQbAHICdNWie05gn3a
L1VHPKIoZOq50MJcKH4lOwBX9kShnuf6VM1THyCzDXXLEKFlw2QYzQR6h4UCW4fQ
/we0NblTy2vMVzYbSTTNE3qY/FVHTW5M8qma6I0AyWILcMKitXoENczDkYxe4BSF
uZTZyP/gr6/8moq3cWUwUFhcpEm4tF/zf84FktlUOzpBfHbylMyXQVoQLekqJW11
cbGjyidfn9e0HJ2h6XC2vAmlq9Ie4P58yGb8Sut2WgdOv1IRk4AP1tmzOqNHXjO5
fD3X4PlbgVZnvHNia5dq
=hMbc
-----END PGP SIGNATURE-----

--fXStkuK2IQBfcDe+--

- Raw text -