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

Pierre Muller
2011-04-01T09:24:08Z

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