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:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type; q=dns; s=default; b=vZeB CfaSek860NqkaSGqTHBzLDqsBAplED5duRVelcYgA0/AQVQxEJxejzCUrFs2tUc4 EiZzvOmFPHqF1eb8cNz+BS4LDHvK2r4AJv4S+AnIy5gh8MOoolVZ2GyYWUr/CB/y /Aj2pZiwF8zxaPCEv8rTT8S4443dXJdVzeBNsiE= 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:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type; s=default; bh=i47Bw0DMUW l7ZpiHMAVtS+/1SYw=; b=jSZ/bVsT7vJS1a/8G7n0WAzFOw4rQljiqGcTwRU/PJ 9sW4vX0fZkv+g7E6UsYU7bZVs/91kBViYlNVaAVOyed4IOUbboIEcjOd3jhmwCw7 CLpLt+rau2UgCEaD/6ZJOzGVlcx8d4zRkty8YSzyxbCCVuys0icRfQGPd+0rWLwi E= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Via, specifiers, Carl, carl X-HELO: mx1.redhat.com DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 808027F6AD Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=eblake AT redhat DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 808027F6AD Subject: bug in lrint [was: FW: Printing long int in C program under cygwin64] To: cygwin AT cygwin DOT com References: <6f28f46906804c6f8f6b4b861e202492 AT CASMBX02 DOT oslo DOT ngi DOT no> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg Message-ID: Date: Wed, 24 May 2017 07:33:27 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <6f28f46906804c6f8f6b4b861e202492@CASMBX02.oslo.ngi.no> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7JoPfwj3w7ah1tQ15k1LeFAHbIUAHL1u7" X-IsSubscribed: yes --7JoPfwj3w7ah1tQ15k1LeFAHbIUAHL1u7 Content-Type: multipart/mixed; boundary="RbWQ7j89rsS9xTTvst9a2bVT9ffqucMC1"; protected-headers="v1" From: Eric Blake To: cygwin AT cygwin DOT com Message-ID: Subject: bug in lrint [was: FW: Printing long int in C program under cygwin64] References: <6f28f46906804c6f8f6b4b861e202492 AT CASMBX02 DOT oslo DOT ngi DOT no> In-Reply-To: <6f28f46906804c6f8f6b4b861e202492 AT CASMBX02 DOT oslo DOT ngi DOT no> --RbWQ7j89rsS9xTTvst9a2bVT9ffqucMC1 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/24/2017 07:00 AM, Carl Fredrik Forsberg wrote: > I am experiencing problems printing long int values under cygwin64 instal= led on a Windows 10 machine. >=20 > Below is a test program followed by its output to demonstrate the problem= . The program was initially written to demonstrate the output from lrint(),= and developed further to demonstrate to myself how negative integers are t= ackled by printf type specifiers (e.g. %li, %ld etc). Are you compiling with -Wall, or even -Wformat? >=20 > My understanding is that lrint() should return a long int. However I am u= nable to get printf to print the correct number. Instead its output is trea= ted as an unsigned integer. > Any help or hints would be much appreciated. >=20 > Regards > Carl Fredrik >=20 > #include /* printf */ > #include /* lrint */ >=20 > int main () > { > char text[64]; > printf ( "int -2 =3D %i\n", -2 ); > printf ( "int -1 =3D %i\n", -1 ); > printf ( "int 0 =3D %i\n", 0 ); > printf ( "int 1 =3D %i\n", 1 ); Okay so far. > printf ( "long int -2 =3D %li\n", -2 ); > printf ( "long int -1 =3D %li\n", -1 ); Both buggy. You are passing an int through varargs, but then telling printf to grab a long int. It may or may not work depending on ABI and stack sizes and what not, but gcc will warn you that it is bogus. > printf ( "type cast -1 =3D %li\n", (long int)-1 ); > printf ( "type cast lrint(-1.0) =3D %li\n", (long int)lrint(-1.0) ); > printf ( "lrint(-1.0) =3D %li\n", lrint(-1.0) ); > printf ( "lrint(1.0) =3D %li\n", lrint(1.0) ); Okay. > printf ( "long int 0 =3D %li\n", 0 ); > printf ( "long int 1 =3D %li\n", 1 ); > sprintf( text,"long int -1 =3D %li", -1 ); Buggy. > printf ( "Via sprintf: %s\n", text); Okay (well, if you overlook the fact that text was populated in a buggy manner) > printf ( "size of long int: %i\n", sizeof(long int)); > printf ( "size of int: %i\n", sizeof(int)); Buggy. size_t should be printed with %zi, not %i (since size_t and int are not necessarily the same type). > return 0; > } >=20 >=20 > compiled by: > gcc lrint_test.c -o lrint_test.exe Missing -Wall. Also, some platforms require the use of -lm to actually link with lrint() (cygwin does not, though). >=20 > Output: >=20 > int -2 =3D -2 > int -1 =3D -1 > int 0 =3D 0 > int 1 =3D 1 > long int -2 =3D 4294967294 > long int -1 =3D 4294967295 Evidence of your bugs. > type cast -1 =3D -1 > type cast lrint(-1.0) =3D 4294967295 Now that's an interesting one - it may be that cygwin1.dll actually has buggy behavior in lrint(). In the source code, cygwin/math/lrint.c is dropping down to assembly; it could very well be that the assembly code is incorrectly truncating things at 32 bits (where it is just fine for 32-bit Cygwin, but wrong for 64-bit): long lrint (double x) { long retval =3D 0L; #if defined(_AMD64_) || defined(__x86_64__) || defined(_X86_) || defined(__i386__) __asm__ __volatile__ ("fistpl %0" : "=3Dm" (retval) : "t" (x) : "st"); #elif defined(__arm__) || defined(_ARM_) retval =3D __lrint_internal(x); #endif return retval; } But I'm not an assembly coding expert, so perhaps someone else will spot the fix faster. > The confidentiality or integrity of this message can not be guaranteed fo= llowing transmission on the Internet. Not the worst disclaimer (it is at least not stating something that is unenforceable), but we do prefer that messages on this list be sent without company legalese (even if that means sending from a personal address instead). --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org --RbWQ7j89rsS9xTTvst9a2bVT9ffqucMC1-- --7JoPfwj3w7ah1tQ15k1LeFAHbIUAHL1u7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJZJX2XAAoJEKeha0olJ0Nq1cgIAKx1B0fe3qOwHm+89twBLxnk 0AHyb1RVeXOQbrn4AMokRmN5rIEIgNJjLonOI8fwS/oaH1790uvpsRQH1FYuKhom v5M5STod4Hx/yZcDyi5JnDGt10y07qinIM6X8bmfCW3OPdyiraxw3Drp3dcmCwZl x0kHiOpstm4a/qpwFI/qLQdLan13tCz3+3ztgdHtiFHGToVBLVTEW7XWzOUdzJsD 2b3jgyAUZMO92evbVDwad2jHCL/144xau9UAZnEVuBWrZXMOqT1/AF/6S0G4u0oI 3qBq2cKTwM3P6aH2HvKH2U6nkkFXD+D0HlZ/IqzvbIqJhtVRG4k1IBuZadTaetc= =vmY5 -----END PGP SIGNATURE----- --7JoPfwj3w7ah1tQ15k1LeFAHbIUAHL1u7--