This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [RFC 1/9] Unify windows specifics into common/windows-hdep files
- From: "Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>
- To: "'Eli Zaretskii'" <eliz at gnu dot org>
- Cc: <gdb-patches at sourceware dot org>
- Date: Fri, 1 Apr 2011 11:23:55 +0200
- Subject: RE: [RFC 1/9] Unify windows specifics into common/windows-hdep files
- References: <00a201cbeed2$a924dfa0$fb6e9ee0$%muller@ics-cnrs.unistra.fr> <83lizwqtz9.fsf@gnu.org> <003f01cbef22$038bef20$0aa3cd60$%muller@ics-cnrs.unistra.fr> <8362qzq93q.fsf@gnu.org> <002e01cbf02b$7a9cafa0$6fd60ee0$%muller@ics-cnrs.unistra.fr> <83tyeipdqc.fsf@gnu.org>
> -----Message d'origine-----
> De?: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Eli Zaretskii
> Envoyé?: vendredi 1 avril 2011 10:39
> À?: Pierre Muller
> Cc?: gdb-patches@sourceware.org
> Objet?: Re: [RFC 1/9] Unify windows specifics into common/windows-hdep
files
>
> > From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> > Cc: <gdb-patches@sourceware.org>
> > Date: Fri, 1 Apr 2011 07:12:42 +0200
> >
> > > > From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> > > > Cc: <gdb-patches@sourceware.org>
> > > > Date: Wed, 30 Mar 2011 23:32:36 +0200
> > > >
> > > > > > +#undef _G_SUFFIX
> > > > >
> > > > > I think the C Standard says that macros whose name begins with an
> > > > > underscore and a capital letter are reserved. Applications should
> not
> > > > > use such macros.
> > > >
> > > > But we are also using __USEWIDE before my patch ...
> > > > or do you mean that two underscores are OK?
> > >
> > > No, AFAIK macros that begin with two underscores are also reserved.
> >
> > But nobody protested for __USEWIDE nor for __PMAX for instance...
> > But checking gdb directory, it seems that are only a fee macros
> > starting with an underscore.
>
> Again, I think it's bad practice to use such macros, but that's me.
> If no one else cares, you can disregard me on that account.
As I know very little about all those rules,
I am perfectly willing to adhere to them.
It will all depend if we try to use the standard UNICODE
macro.
By the way, I noticed that in /usr/include/w32api/winnt.h
#ifdef UNICODE
/*
* NOTE: This tests UNICODE, which is different from the _UNICODE define
* used to differentiate standard C runtime calls.
*/
so it seems that we would probably need both UNICODE and _UNICODE
_UNICODE is used solely in /usr/include/mingw/tchar.h header
and defined _tprintf to be either wprintf or printf
and a long list of similar functions.
But this can only be used in mingw specific code as
those macros do not seem to exist for Cygwin.
> > > > > > +# define CreateProcess CreateProcessW
> > > > > > +# define GetSystemDirectory GetSystemDirectoryW
> > > > > > +# define windows_strlen wcslen
> > > > >
> > > > > Ouch! So any API that needs one of the two varieties will need to
> be
> > > > > added to this list of #define's? Is that wise?
> > > >
> > > > Isn't it better than being forced to use
> > > > #ifdef __USEWIDE
> > > > CreateProcessW (...
> > > > #else
> > > > CreateProcessA (...
> > > > #endif
> > >
> > > The Windows headers already have the machinery to do all this for you:
> > > it works by defining _UNICODE.
According to the note above it is UNICODE, not _UNICODE.
> >
> > But using this macro would require that we are able to
> > put of the code that decides if we want to use the Unicode or ASCII
> version
> > of the windows header before even including it.
>
> Sorry, I'm not following. What difficulties you envision.
>
> In general, I don't think we should drag into GDB the stuff MinGW
> headers do to "transparently" support compile-time selection of ANSI
> vs Unicode APIs. I think we should use the mechanism provided for
> that by the headers. That mechanism is to define _UNICODE.
Here also, it's UNICODE, not _UNICODE.
But the question of being sure that winnt.h header was not included
before would still be a potential problem...
> > If you look at the code in common/windows-hdep.c I submitted,
> > you will see that we need at least to load sys/cygwin.h and
> > cygwin/version.h headers
> > in order to be able to compute the Cygwin DLL version.
> > Each might already also include windows.h
> > meaning than setting _UNICODE at that point would be too late.
> I don't know enough about the Cygwin part of this, so maybe you are
> right. But in that case, we should have explicit code that selects
> either ..A or ..W variety of the API at run time, instead of hiding
> them in a header using #define's.
Supporting the two (Unicode and ASCII) versions at run time
would be another patch that might be not so easy to implement...
I only tried to expand the possibility to use Unicode Windows API version
to use with mingw hosts, and kept most of the macros that
were in windows-nat.c but moved them to common/windows-hdep.h header.
Pierre