Re: [RFC 1/9] Unify windows specifics into common/windows-hdep files

[Eli Zaretskii <eliz@gnu.org>]

> 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.

> > > > > +# 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.
> 
>   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.

> 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.