From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20876 invoked by alias); 1 Apr 2011 09:24:08 -0000 Received: (qmail 20864 invoked by uid 22791); 1 Apr 2011 09:24:06 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,MSGID_MULTIPLE_AT X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.153) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 01 Apr 2011 09:24:01 +0000 Received: from md1.u-strasbg.fr (md1.u-strasbg.fr [IPv6:2001:660:2402::186]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id p319NvbY085374 ; Fri, 1 Apr 2011 11:23:57 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [130.79.204.11]) by md1.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id p319NuEP082937 ; Fri, 1 Apr 2011 11:23:57 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from E6510Muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id p319NuOY056921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) ; Fri, 1 Apr 2011 11:23:56 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: "'Eli Zaretskii'" Cc: 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> In-Reply-To: <83tyeipdqc.fsf@gnu.org> Subject: RE: [RFC 1/9] Unify windows specifics into common/windows-hdep files Date: Fri, 01 Apr 2011 09:24:00 -0000 Message-ID: <002001cbf04e$8681f410$9385dc30$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-04/txt/msg00003.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Eli Zaretskii > Envoy=E9=A0: vendredi 1 avril 2011 10:39 > =C0=A0: Pierre Muller > Cc=A0: gdb-patches@sourceware.org > Objet=A0: Re: [RFC 1/9] Unify windows specifics into common/windows-hdep files >=20 > > From: "Pierre Muller" > > Cc: > > Date: Fri, 1 Apr 2011 07:12:42 +0200 > > > > > > From: "Pierre Muller" > > > > Cc: > > > > 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. >=20 > 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. =20 > > > > > > +# 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. >=20 > Sorry, I'm not following. What difficulties you envision. >=20 > 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=20 before would still be a potential problem... =20 > > 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.=20 > 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