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

["Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>]

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