From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 69A031F803 for ; Tue, 8 Jan 2019 13:23:32 +0000 (UTC) Received: from localhost ([127.0.0.1]:32880 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ggrLo-0000Wu-1c for normalperson@yhbt.net; Tue, 08 Jan 2019 08:23:24 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42688) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ggrLW-0000Pk-5e for bug-gnulib@gnu.org; Tue, 08 Jan 2019 08:23:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ggrLU-0002Ng-1H for bug-gnulib@gnu.org; Tue, 08 Jan 2019 08:23:05 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:55067) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ggrLT-0001xA-CP for bug-gnulib@gnu.org; Tue, 08 Jan 2019 08:23:03 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3346325EE1; Tue, 8 Jan 2019 08:22:57 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute2.internal (MEProxy); Tue, 08 Jan 2019 08:22:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beauzee.fr; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=fm2; bh=O1r o96XnXXMUlUQb2+0scvzIIUlu8kTFpqyfLCRKxj8=; b=X4ez+LdQuWrKd84vMFA Keyj27i2LbQqA/1D+JL+8uG6if243U+msAN9BLzM0mYBUHGJdB3aFOY0UD0oJpao QDHkEaOuxERmc1r5gEYUP6XOzVS0jOMjplXf/OxvUlpZDLvfSyy6U1/yHzEmfsyw tKIOQxHCNXhP/YpqemzxXiJWlIbZJAfoghvy4lODu+3eB8CLuMba4Yesi2Vn3Tx2 2ZfWxVmzT6UUn3lIMvCc4vxbba3j/runpf7SgL+pzvSGAo6L5Kt2a5JoqJt+wdgG ZZ7i/H5IGMzM1S120zrfajqesIajDC5RvYXbOwEJCMjDUU2UTtVNQrst2TAHCnFl rIw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=O1ro96XnXXMUlUQb2+0scvzIIUlu8kTFpqyfLCRKx j8=; b=FYdomJVK3ZEEj4Yb2bX1mlmHqH5PMWG0810erk2NB2eIB2UgFFpTs0bXM bRv6nOAdBic3Pl3ubL+E0pbEN8aFTnSonkoRGHcLSUYaZh16RsfNxNgGDb0S+42T 9xL6QhIYzC1fnK6JEnBy94pnlPHyiRc5/NtulVK0UPGGa1XOLopFKgNUVykvTcY4 ZKSf+lVaa+72JYkfjjiP6/wFC/G7wLEX/kx2dkshGajlS4Ci/DzT5Ra0tq9P+i4i eFqCwrvW9IEQhs5nbXSvNsIMIJAodZgn8PGbmnhzBUjTrSgZxTGvNc4DwcHgmfWe VqpLgS2gfa+3XOXs3oqWJV/OC4HFw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdelgdehtdculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkffhvfgggfgtofgjfhfuffesthhqredtredtjeenucfhrhhomhepjfhughho uceuvggruhiirogvqdfnuhihshhsvghnuceohhhughhosegsvggruhiivggvrdhfrheqne cuffhomhgrihhnpehgohhoghhlvghsohhurhgtvgdrtghomhenucfrrghrrghmpehmrghi lhhfrhhomhephhhughhosegsvggruhiivggvrdhfrhenucevlhhushhtvghrufhiiigvpe dt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3766C62323; Tue, 8 Jan 2019 08:22:56 -0500 (EST) Message-Id: <1546953776.929786.1628734480.63B022C2@webmail.messagingengine.com> From: =?utf-8?Q?Hugo=20Beauz=C3=A9e-Luyssen?= To: Bruno Haible , bug-gnulib@gnu.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5ae1f753 In-Reply-To: <10809045.kCnJR5hbVe@omega> References: <20181219095440.22626-1-hugo@beauzee.fr> <10809045.kCnJR5hbVe@omega> Subject: Re: [PATCH] vasnprintf: Don't use %n on android Date: Tue, 08 Jan 2019 14:22:56 +0100 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.25 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On Thu, Dec 20, 2018, at 2:53 AM, Bruno Haible wrote: > Hi, >=20 > Hugo Beauz=C3=A9e-Luyssen wrote: > > 12-14 19:10:02.633 F DEBUG : pid: 31664, tid: 32389, name: VlcObject = >>> org.videolan.vlc <<< > > 12-14 19:10:02.633 F DEBUG : signal 6 (SIGABRT), code -1 (SI_QUEUE), = fault addr -------- > > 12-14 19:10:02.633 F DEBUG : Abort message: 'FORTIFY: %n not allowed = on Android' >=20 > Indeed, %n in *printf is not allowed on Android, see > https://android.googlesource.com/platform/bionic/+/master/libc/stdio/vfpr= intf.cpp > https://android.googlesource.com/platform/bionic/+/master/docs/status.md >=20 > > diff --git a/lib/vasnprintf.c b/lib/vasnprintf.c > > index af3fcd1c7..e41d5f706 100644 > > --- a/lib/vasnprintf.c > > +++ b/lib/vasnprintf.c > > @@ -4874,7 +4874,8 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp, > > # if ! (((__GLIBC__ > 2 || (__GLIBC__ =3D=3D 2 && __GLIBC_MINOR__ >=3D= 3)) \ > > && !defined __UCLIBC__) = \ > > || (defined __APPLE__ && defined __MACH__) = \ > > - || (defined _WIN32 && ! defined __CYGWIN__)) > > + || (defined _WIN32 && ! defined __CYGWIN__) = \ > > + || defined __ANDROID__) > > fbp[1] =3D '%'; > > fbp[2] =3D 'n'; > > fbp[3] =3D '\0'; >=20 > The patch looks good at first sight. But when you look at the comments a > couple of lines before it, you see that one can avoid %n only > if snprintf behaves well enough. To this effect, can you please report > the configure results (from a *native* Android compilation, not a cross- > compilation) of these tests: >=20 > 1 =3D checking whether printf supports size specifiers as in C99... > 2 =3D checking whether printf supports 'long double' arguments... > 3 =3D checking whether printf supports infinite 'double' arguments... > 4 =3D checking whether printf supports infinite 'long double' arguments... > 5 =3D checking whether printf supports the 'a' and 'A' directives... > 6 =3D checking whether printf supports the 'F' directive... > 7 =3D checking whether printf supports the 'n' directive... > 8 =3D checking whether printf supports the 'ls' directive... > 9 =3D checking whether printf supports POSIX/XSI format strings with posi= tions... > 10 =3D checking whether printf supports the grouping flag... > 11 =3D checking whether printf supports the left-adjust flag correctly... > 12 =3D checking whether printf supports the zero flag correctly... > 13 =3D checking whether printf supports large precisions... > 14 =3D checking whether printf survives out-of-memory conditions... > 15 =3D checking for snprintf... > 16 =3D checking whether snprintf truncates the result as in C99... > 17 =3D checking whether snprintf returns a byte count as in C99... > 18 =3D checking whether snprintf fully supports the 'n' directive... > 19 =3D checking whether snprintf respects a size of 1... > 20 =3D checking whether vsnprintf respects a zero size as in C99... >=20 > You should find these in the configure output of any package that > uses gnulib's 'vasnprintf' module. If you don't have one at hand, > create one using > ./gnulib-tool --create-testdir --dir=3Dtestdir --single-configure vasnp= rintf >=20 > Thanks. >=20 > Bruno >=20 Hi, I'm probably missing something, but for me this only seems to test for snpr= intf/printf/vasnprintf availability (including running configure in the gen= erated test directory) Regards, --=20 Hugo Beauz=C3=A9e-Luyssen hugo@beauzee.fr