From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7640 invoked by alias); 18 Dec 2013 17:31:59 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 7628 invoked by uid 89); 18 Dec 2013 17:31:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Dec 2013 17:31:57 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 938CD1A082F; Wed, 18 Dec 2013 18:31:55 +0100 (CET) Date: Wed, 18 Dec 2013 17:31:00 -0000 From: Corinna Vinschen To: gdb-patches@sourceware.org Subject: Re: [RFA] Fix cygwin compilation failure due to nameless LOAD_DLL_DEBUG_EVENT causes ntdll.dll to be missing Message-ID: <20131218173155.GA30010@calimero.vinschen.de> Reply-To: gdb-patches@sourceware.org Mail-Followup-To: gdb-patches@sourceware.org References: <52ab8d0e.8aa2420a.30ff.ffffd8f1SMTPIN_ADDED_BROKEN@mx.google.com> <52AF3493.9090708@redhat.com> <20131218112045.GQ30010@calimero.vinschen.de> <83bo0ecgdw.fsf@gnu.org> <20131218160707.GV30010@calimero.vinschen.de> <834n66ccs9.fsf@gnu.org> <20131218171819.GY30010@calimero.vinschen.de> <831u1acblu.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="90KBcPA0h13nTGdQ" Content-Disposition: inline In-Reply-To: <831u1acblu.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00715.txt.bz2 --90KBcPA0h13nTGdQ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1425 On Dec 18 19:28, Eli Zaretskii wrote: > > Date: Wed, 18 Dec 2013 18:18:19 +0100 > > From: Corinna Vinschen > >=20 > > On Dec 18 19:03, Eli Zaretskii wrote: > > > > Date: Wed, 18 Dec 2013 17:07:07 +0100 > > > > > Are you sure that 32K capability cannot be had with ANSI file nam= es > > > > > using the \\?\ notation? > > > >=20 > > > > Yes. The \\?\ notation only works in the UNICODE API[*]. The reas= on > > > > is that the ANSI API is just a thin layer over the actual UNICODE > > > > functionality, and the conversion from ANSI to UNICODE is done usin= g a > > > > per-thread fixed-size buffer of 520 bytes. > > >=20 > > > Does this mean that using \\?\ with ANSI-encoded file names buys us > > > 520-byte file names? > >=20 > > 260 char ANSI -> 520 bytes UTF-16 >=20 > Oh, I misunderstood then. >=20 > So lifting the 260-char limit means both go to Unicode _and_ use the > \\?\ format of file names, is that right? Right. > If so, it probably means > that CRT functions that accept wchar_t arrays as file names (_wfopen > etc.) cannot be used with such long file names, and one needs to call > the Win32 APIs directly. Correct? I don't know, but I doubt it. The filenames in case of calling the _wfopen functions are probably sent directly to the underlying WIn32 functions. There's no good reason to drop the long path prefixes. Corinna --=20 Corinna Vinschen Cygwin Maintainer Red Hat --90KBcPA0h13nTGdQ Content-Type: application/pgp-signature Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJSsdwLAAoJEPU2Bp2uRE+gUrgP/RkgxnJvhYuI6iQSOjofQa78 a9cJea5STicpToqoKwphjJv/6CRT5kHO3psnb90ZndEWHpJIK7wxTlqNHh25qWIy IbRZWrIJhkysMHHqORSWcpQCdWRzQaWDpyJObit2uIZv7cXxLEP/sWwAir1wucIj +nZlfHTbdiXN0ALR+A4n9dC6LJgLkDjUW8dtvpPfogSvIktZ3mBa3n5M248H46OK w4kvFa3eo/jdbLLwD1iIb+ETql4MHt8x+OawQiNXoDZXQGjEth2dOQWAurSYL9/z R++h82f9AROIDEncKk4e916jxH5sbhzfB0+V2MyoXsZXINJN3bi8kB8sXtX0nOlK xiY7zfU3XbUQhGfwCB5hlbfx9UCvw8JEGbOYnDoWuJe94HLSztmowrCyYh7zcwAL ptPT6ZPDMDaDnGcQQoBkG9sYDSSFHmF2PXnuPw2TxkjRsvwMu1FwahDP1I98DfCV l+QY8gyiDGj8Jcjm3aITYKq2G7FNSETODUbOe5hZ5okOMSvuPVBneNbMo6Jk7j5+ 67hGVMPToy0yfm+1tKcQ5gdxqo+1PAh2OhW8UDYPDYqTDDgf03O9rXq5yq/0g7xw UTSUL8fMRPy9nW9lh1bVUadACxtsIUfAsBpiol864JG57dFEmAHmWZVHi+M+R0eR aHRnmvEzPuYFedL27LlW =iLbZ -----END PGP SIGNATURE----- --90KBcPA0h13nTGdQ--