From: Corinna Vinschen <vinschen@redhat.com>
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
Date: Wed, 18 Dec 2013 11:20:00 -0000 [thread overview]
Message-ID: <20131218112045.GQ30010@calimero.vinschen.de> (raw)
In-Reply-To: <52AF3493.9090708@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]
On Dec 16 17:12, Pedro Alves wrote:
> On 12/13/2013 10:37 PM, Pierre Muller wrote:
> > Following this thread
> > https://sourceware.org/ml/gdb-patches/2013-12/msg00073.html
> >
> > The patch
> > https://sourceware.org/ml/gdb-cvs/2013-12/msg00054.html
> >
> > introduced a failure for cygwin native build.
> > The problem is that __USEWIDE is not considered in the patch.
> >
> > The patch below fixes this compilation error
> > and should allow cygwin to work as mingw.
>
> Looks fine to me.
>
> (Though I wonder why not just use GetModuleFileNameExA
> explicitly. In fact, it's what gdbserver does).
Maybe I'm a bit late, but I'd like to chime in here. Don't use
GetModuleFileNameExA, use GetModuleFileNameExW.
In theory, you should never use the ANSI API on Windows, unless you're
still building GDB for Windows 9x, which should be really, really dead
by now, hopefully.
The reasons are:
- The ANSI API only supports a single- or doublebyte codeset in almost
all language versions of Windows. There are only a handful languages
which are using UTF-8 as ANSI codeset on Windows, most use something
like CP1252 or some other codeset which is not capable of handling all
UNICODE characters.
- The ANSI API restricts filenames to MAX_PATH (260) characters, while
the UNICODE API and the underlying OS allow paths of up to 32K.
Cygwin is using the UNICODE and native NT APIs exclusively, so paths in
Cygwin are only restricted by the maximum OS capability of 32K, and the
influence of the PATH_MAX setting of 4096.
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-12-18 11:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <52ab8d0e.8aa2420a.30ff.ffffd8f1SMTPIN_ADDED_BROKEN@mx.google.com>
2013-12-16 17:13 ` Pedro Alves
2013-12-16 22:50 ` Pierre Muller
2013-12-18 11:20 ` Corinna Vinschen [this message]
[not found] ` <83bo0ecgdw.fsf@gnu.org>
2013-12-18 16:07 ` Corinna Vinschen
2013-12-18 17:03 ` Eli Zaretskii
2013-12-18 17:18 ` Corinna Vinschen
2013-12-18 17:29 ` Eli Zaretskii
2013-12-18 17:31 ` Corinna Vinschen
2013-12-18 18:19 ` Eli Zaretskii
2013-12-18 19:18 ` Corinna Vinschen
2013-12-18 20:01 ` Eli Zaretskii
2013-12-18 20:54 ` Corinna Vinschen
2013-12-19 18:33 ` Eli Zaretskii
2013-12-28 3:17 ` Joel Brobecker
2013-12-28 9:02 ` Eli Zaretskii
2013-12-13 22:41 Pierre Muller
2013-12-16 2:21 ` Yao Qi
2013-12-16 18:05 ` Pedro Alves
2013-12-17 0:43 ` Yao Qi
2013-12-17 8:43 ` Pierre Muller
2013-12-18 3:37 ` Yao Qi
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=20131218112045.GQ30010@calimero.vinschen.de \
--to=vinschen@redhat.com \
--cc=gdb-patches@sourceware.org \
/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